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Foreword 


Business processes represent a core asset of corporations. They have direct impact 
on the attractiveness of products and services as perceived by the market. They 
determine tasks, jobs and responsibilities and by this, shape the work of every em- 
ployee. Processes integrate systems, data, and resources within and across organi- 
zations and any failure can bring corporate life to a standstill. Processes determine 
the potential of an organization to adapt to new circumstances and to comply with 
a fast growing number of legislative requirements. Processes influence the revenue 
potential as much as they shape the cost profile of an organization. 

However, unlike other corporate assets such as products, services, workforce, 
brand, physical or monetary assets, the significance of business processes had not 
been appreciated for a long period. Despite the fact that processes are the lifeblood 
of an organization, they did not develop the status of a primary citizen in boardroom 
discussions and managerial decision-making processes. 

Only the growing demands for globalization, integration, standardization, inno- 
vation, agility and operational efficiency, and the related challenge of finding further 
variables in the corporate ecosystem that can be optimized, have finally increased 
the appetite for reflecting on and ultimately improving business processes. 

In response, over the last two decades a comprehensive set of tools, techniques, 
methods and entire methodologies has been developed providing support for all 
stages of the business process lifecycle. Relevant contributions have been made by 
diverse disciplines such as Industrial Engineering, Operations Management, Qual- 
ity Management, Human Capital Management, corporate governance, conceptual 
modeling, workflow management and system engineering. 

Business Process Management (BPM) is the discipline that now faces the diffi- 
cult, but rewarding task of consolidating and integrating the plethora of these ap- 
proaches. 

This book is the first and most up-to-date contribution that faces and masters this 
challenge. It succinctly captures the current status of BPM and brings meaningful 
order and consistency into approaches that often have been developed, discussed 
and deployed in isolation. 


Vii 


Vili Foreword 


“Fundamentals of Business Process Management” derives its merits from its 
firm foundation in the latest applied BPM research. Relying on scientifically sound 
practices means capitalizing on evidence rather than depending on confidence. This 
clearly differentiates this much needed publication from many of its predecessors. 
In particular, it gives BPM the credibility that a still young and growing discipline 
requires. 

The book itself is also a compelling showcase for the importance of a new class of 
processes, i.e. long living, internationally distributed, complex and flexible business 
processes. In this case, it is the process of jointly writing a book involving four 
authors in four different countries. The team has addressed this challenge brilliantly 
and the outcome is an impressive compilation of the individual strengths of each 
author grounded in a shared understanding of the essential BPM fundamentals and 
a common passion for the topic. 

I have no doubts that this book will shape the toolset, and hopefully even more 
the mindset, of the current and future generations of BPM professionals. This pub- 
lication has the potential to become a significant catalyst for future BPM success 
by establishing a common sense for the fundamentals of BPM upon which it can 
be further developed and tailored to individual circumstances. The book provides 
the needed consistency and rigor within and across the diverse and fast growing 
community of professionals and researchers committed to and passionate about the 
merits of the process-based organization. 

Finally, and maybe most of all, the book is an outstanding reference for all stu- 
dents who are keen to learn more about and want to embrace the fascination of 
BPM. This long missing BPM textbook addresses a severe shortcoming within the 
BPM community, i.e. the lack of resources to facilitate the introduction of BPM sub- 
jects into tertiary and corporate education. Making BPM more accessible to future 
decision makers ensures that processes will play the role they deserve. 


Brisbane, Australia Michael Rosemann 


Preface 


First, master the fundamentals. 
Larry Bird (1957-) 


Business Process Management (BPM) is a special field for more than one reason. 
First of all, BPM is a crossroad of multiple, quite different viewpoints. Business 
managers are attracted to BPM because of its demonstrated ability to deliver im- 
provements in organizational performance, regulatory compliance and service qual- 
ity. Industrial engineers see BPM as an opportunity to apply well-trodden manufac- 
turing optimization techniques in the context of organizations that deliver services 
rather than physical products. Finally, Information Technology (IT) specialists ap- 
preciate the fact that BPM provides them with a shared language to communicate 
with business stakeholders. Furthermore, business process automation technology 
allows IT specialists to implement and monitor IT systems in a way that is aligned 
with the vision that business stakeholders have of the organization. In other words, 
BPM is a boundary-spanning field that serves as a melting pot for otherwise separate 
communities. For those who have experienced how business managers, industrial 
engineers and IT professionals often seem to live in different worlds, this shared 
field of interest is a remarkable opportunity to achieve a joint understanding of the 
inner workings of a business. 

A second special characteristic of BPM is that it is both actively practiced and 
actively researched. In other words, it is a field where there are both proven and es- 
tablished practices as well as open challenges. Businesses around the world are car- 
rying out BPM initiatives with the aim to, for example, outperform their competitors 
or meet the demands of regulatory authorities. Academics in fields like computer 
science, management science, sociology, and engineering are working on the devel- 
opment of methods and techniques to support such initiatives. It is appropriate to see 
BPM as a “theory in practice” field. On the one hand, practical demands inspire the 
development of new methods and technologies. On the other hand, the application 
of these methods and technologies in practice feeds back to the drawing boards in 
universities and research centers. 

After teaching BPM to thousands of students and professionals over the past 
decade, we strongly feel the lack of a textbook to give a structure to our courses 
and to allow our audience to study for themselves beyond classwork and homework 
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assignments. This situation is not due to a lack of excellent books on BPM—in 
fact there is a good number of them—but rather due to the cross-disciplinary and 
continuously evolving nature of BPM. 

There are excellent treatments of BPM from a business management perspec- 
tive, most notably Harmon’s Business Process Change and Sharp and McDermott’s 
Workflow Modeling. Both of these books provide useful conceptual frameworks and 
practical advice and should definitely lie in the bookshelves (or better in the hands) 
of BPM practitioners. However, one needs an introductory background and prefer- 
ably years of experience in order to truly appreciate the advice given in these books. 
Also, these books give little attention to technology aspects such as business process 
management systems and process intelligence tools. 

On the other side of the spectrum, other books adopt a computer science per- 
spective to BPM, such as Van der Aalst and Van Hee’s Workflow Management and 
Weske’s Business Process Management, both focused on process modeling, anal- 
ysis and automation for computer scientists. At a more specialized level, one can 
find a range of books focusing on process modeling using specific languages—for 
example Silver’s BPMN Method and Style. 

Against this background, we decided it was time to put together our combined 
teaching experience in BPM in order to deliver a textbook that: 


e Embraces BPM as a cross-disciplinary field, striking a balance between business 
management and IT aspects. 

e Covers the entire BPM lifecycle, all the way from identifying processes to ana- 
lyzing, redesigning, implementing and monitoring these processes. 

e Follows a step-by-step approach punctuated by numerous examples, in order to 
make the content accessible to students who have little or no BPM background. 

e Contains numerous classroom-tested exercises, both inside each chapter and at 
the end of the chapters, so that students can test their skills incrementally and 
instructors have material for classwork, homework and projects. 

e Relies on a mature and standardized process modeling language, namely BPMN. 


In the spirit of a textbook, every chapter contains a number of elaborated exam- 
ples and exercises. Some of these exercises are spread throughout the chapter and 
are intended to help the reader to incrementally put into action concepts and tech- 
niques exposed in the chapter in concrete scenarios. These “in-chapter” exercises 
are paired with sample solutions at the end of the chapter. In addition, every chap- 
ter closes with a number of further exercises for which no solutions are provided. 
Instructors may wish to use these latter exercises for assignments. 

Most chapters also contain “highlighted boxes” that provide complementary in- 
sights into a specific topic. These boxes are tangential to the flow of the book and 
may be skipped by readers who wish to concentrate on the essential concepts. Sim- 
ilarly, every chapter closes with a “Further Readings” section that provides external 
pointers for readers wishing to deepen their understanding of a specific topic. 

To better serve our readership, we have set up a website to collect course mate- 
rials: http://fundamentals-of-bpm.org. This website includes slides, lecture record- 
ings, sample exams, links to related resources and additional exercises. 
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The book is designed to support courses of a wide variety. An in-depth course 
on BPM could cover all chapters in a balanced way. In order to fit the content into 
one semester though, it may be necessary to sacrifice one or two chapters. If this 
was required, our suggestion would be to skip Chap. 4 or 10. An introductory BPM 
course could skip Chaps. 2, 4, 7 and 10 while still providing a consistent picture 
of the field. A course on process automation for IT students could skip Chaps. 2, 5 
and 6. A course on process modeling would focus on Chaps. 2 to 5, and possibly 
Chap. 9 if the intention is to produce executable process models. Chapters 3 and 4 
can be integrated into a broader semester-long course on systems modeling. Finally, 
a process improvement course for business students might focus on Chap. 3 and 
Chaps. 5 to 8. Naturally, Chap. | could find its place in any of the above courses. 

Each chapter can be delivered as a combination of lectures and classwork ses- 
sions. Shorter chapters (1, 2, 3, 5, 6 and 10) can be delivered in one lecture and one 
classwork session. Chapters 4, 8 and 9 may require two lectures and two classwork 
sessions each. Chapter 7 can be delivered across two lectures and two classwork 
sessions, or it can be delivered in one lecture and one classwork session by skipping 
the content on queues and flow analysis. 

This textbook is the result of many years of educational practice both at the un- 
dergraduate and postgraduate levels in more than half a dozen institutions, including 
Eindhoven University of Technology (The Netherlands), Queensland University of 
Technology (Australia), Humboldt University of Berlin (Germany), University of 
Tartu (Estonia), Vienna University of Economics and Business (Austria) and Na- 
tional University of Colombia. The material in this textbook has also served as a 
basis for professional training courses delivered to organizations in Australia, The 
Netherlands and elsewhere. We are grateful to the thousands of students who over 
the past years have given us constructive feedback and encouragement. 

We also owe a lot to our many colleagues who encouraged us and provided 
us with feedback throughout the entire idea-to-textbook process. We would like to 
thank Wil van der Aalst, Raffaele Conforti, Monika Malinova, Johannes Prescher, 
Artem Polyvyanyy, Manfred Reichert, Jan Recker, Michael Rosemann, Matthias 
Schrepfer, Arthur ter Hofstede, Irene Vanderfeesten, J. Leon Zhao and Michael zur 
Muehlen, who all provided constructive feedback on drafts of the book. Fabio Casati 
and Boualem Benatallah provided us with initial encouragement to start the writing 
process. Special mentions are due to Matthias Weidlich who provided us with de- 
tailed and comprehensive suggestions, and Remco Dijkman who shared with us 
teaching material that served as input to Chaps. 2 and 9. 


Tartu, Estonia Marlon Dumas 
Brisbane, Australia Marcello La Rosa 
Vienna, Austria Jan Mendling 


Eindhoven, The Netherlands Hajo A. Reijers 
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Chapter 1 
Introduction to Business Process Management 


Ab ovo usque ad mala. 
Horace (65 BCE-8 BCE) 


Business Process Management (BPM) is the art and science of overseeing how work 
is performed in an organization to ensure consistent outcomes and to take advantage 
of improvement opportunities. In this context, the term “improvement” may take dif- 
ferent meanings depending on the objectives of the organization. Typical examples 
of improvement objectives include reducing costs, reducing execution times and re- 
ducing error rates. Improvement initiatives may be one-off, but also display a more 
continuous nature. Importantly, BPM is not about improving the way individual ac- 
tivities are performed. Rather, it is about managing entire chains of events, activities 
and decisions that ultimately add value to the organization and its customers. These 
“chains of events, activities and decisions” are called processes. 

In this chapter, we introduce a few essential concepts behind BPM. We will start 
with a description of typical processes that are found in contemporary organizations. 
Next, we discuss the basic ingredients of a business process and we provide a def- 
inition for the concept as well as of BPM. In order to place BPM in a broader per- 
spective, we then provide a historical overview of the BPM discipline. Finally, we 
discuss how a BPM initiative in an organization typically unfolds. This discussion 
leads us to the definition of a BPM lifecycle around which the book is structured. 


1.1 Processes Everywhere 


Every organization—be it a governmental body, a non-profit organization, or an 
enterprise—has to manage a number of processes. Typical examples of processes 
that can be found in most organizations include: 


e Order-to-cash: This is a type of process performed by a vendor, which starts 
when a customer submits an order to purchase a product or a service and ends 
when the product or service in question has been delivered to the customer and 
the customer has made the corresponding payment. An order-to-cash process en- 
compasses activities related to purchase order verification, shipment (in the case 
of physical products), delivery, invoicing, payment receipt and acknowledgment. 
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e Quote-to-order: This type of process typically precedes an order-to-cash process. 
It starts from the point when a supplier receives a “Request for Quote” (RFQ) 
from a customer and ends when the customer in question places a purchase order 
based on the received quote. The order-to-cash process takes the relay from that 
point on. The combination of a quote-to-order and the corresponding order-to- 
cash process is called a quote-to-cash process. 

e Procure-to-pay: This type of process starts when someone in an organization de- 
termines that a given product or service needs to be purchased. It ends when 
the product or service has been delivered and paid for. A procure-to-pay process 
includes activities such as obtaining quotes, approving the purchase, selecting a 
supplier, issuing a purchase order, receiving the goods (or consuming the service), 
checking and paying the invoice. A procure-to-pay process can be seen as the dual 
of quote-to-cash process in the context of business-to-business interactions. For 
every procure-to-pay process there is a corresponding quote-to-cash process on 
the supplier’s side. 

e Issue-to-resolution. This type of process starts when a customer raises a problem 
or issue, such as a complaint related to a defect in a product or an issue en- 
countered when consuming a service. The process continues until the customer, 
the supplier, or preferably both of them, agree that the issue has been resolved. 
A variant of this process can be found in insurance companies that have to deal 
with “insurance claims”. This variant is often called claim-to-resolution. 

e Application-to-approval. This type of process starts when someone applies for a 
benefit or privilege and ends when the benefit or privilege in question is either 
granted or denied. This type of process is common in government agencies, for 
example when a citizen applies for a building permit or when a businessman 
applies for a permit to open a business (e.g. a restaurant). Another process that 
falls into this category is the admissions process in a university, which starts when 
a student applies for admission into a degree. Yet another example is the process 
for approval of vacation or special leave requests in a company. 


As the above examples illustrate, business processes are what companies do 
whenever they deliver a service or a product to customers. The way processes are de- 
signed and performed affects both the “quality of service” that customers perceive 
and the efficiency with which services are delivered. An organization can outper- 
form another organization offering similar kinds of service if it has better processes 
and executes them better. This is true not only of customer-facing processes, but 
also of internal processes such as the procure-to-pay process, which is performed 
for the purpose of fulfilling an internal need. 

As we go along this book, we will use a concrete example of a procure-to-pay 
process for renting construction equipment, as described below. 


Example 1.1 Procure-to-pay process at BuildIT. 


BuildIT is a construction company specialized in public works (roads, bridges, pipelines, 
tunnels, railroads, etc.). Within BuildIT, it often happens that engineers working at a con- 
struction site (called site engineers) need a piece of equipment, such as a truck, an excavator, 


1.2 Ingredients of a Business Process 3 


a bulldozer, a water pump, etc. BuildIT owns very little equipment and instead it rents most 
of its equipment from specialized suppliers. 

The existing business process for renting equipment goes as follows. When site engineers 
need to rent a piece of equipment, they fill in a form called “Equipment Rental Request” 
and send this request by e-mail to one of the clerks at the company’s depot. The clerk at 
the depot receives the request and, after consulting the catalogs of the equipment suppliers, 
selects the most cost-effective equipment that complies with the request. Next, the clerk 
checks the availability of the selected equipment with the supplier via phone or e-mail. 
Sometimes the selected option is not available and the clerk has to select an alternative 
piece of equipment and check its availability with the corresponding supplier. 

Once the clerk has found a suitable piece of equipment available for rental, the clerk adds 
the details of the selected equipment to the rental request. Every rental request has to be 
approved by a works engineer, who also works at the depot. In some cases, the works 
engineer rejects the equipment rental request. Some rejections lead to the cancellation of 
the request (no equipment is rented at all). Other rejections are resolved by replacing the 
selected equipment with another equipment—such as a cheaper piece of equipment or a 
more appropriate piece of equipment for the job. In the latter case, the clerk needs to perform 
another availability enquiry. 

When a works engineer approves a rental request, the clerk sends a confirmation to the 
supplier. This confirmation includes a Purchase Order (PO) for renting the equipment. The 
PO is produced by BuildIT’s financial information system using information entered by 
the clerk. The clerk also records the engagement of the equipment in a spreadsheet that is 
maintained for the purpose of tracking all equipment rentals. 

In the meantime, the site engineer may decide that the equipment is no longer needed. In 
this case, the engineer asks the clerk to cancel the request for renting the equipment. 

In due time, the supplier delivers the rented equipment to the construction site. The site 
engineer then inspects the equipment. If everything is in order, the engineer accepts the 
engagement and the equipment is put into use. In some cases, the equipment is sent back 
because it does not comply with the requirements of the site engineer. In this case, the site 
engineer has to start the rental process all over again. 

When the rental period expires, the supplier comes to pick up the equipment. Sometimes, 
the site engineer asks for an extension of the rental period by contacting the supplier via 
e-mail or phone |—2 days before pick-up. The supplier may accept or reject this request. 

A few days after the equipment is picked up, the equipment’s supplier sends an invoice 
to the clerk by e-mail. At this point, the clerk asks the site engineer to confirm that the 
equipment was indeed rented for the period indicated in the invoice. The clerk also checks 
if the rental prices indicated in the invoice are in accordance with those in the PO. After 
these checks, the clerk forwards the invoice to the financial department and the finance 
department eventually pays the invoice. 
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The above example shows that a business process encompasses a number of events 
and activities. Events correspond to things that happen atomically, meaning that they 
have no duration. The arrival of an equipment at a construction site is an event. This 
event may trigger the execution of series of activities. For example, when a piece of 
equipment arrives, the site engineer inspects it. This inspection is an activity, in the 
sense that it takes time. 

When an activity is rather simple and can be seen as one single unit of work, we 
call it a task. For example, if the inspection that the site engineer performs is quite 
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simple—e.g. just checking that the equipment received corresponds to what was 
ordered—we can say that the equipment inspection is a task. If on the other hand 
the equipment inspection requires many steps—such as checking that the equipment 
fulfills the specification included in the purchase order, checking that the equipment 
is in working order, and checking the equipment comes with all the required acces- 
sories and safety devices—we will call it an activity. 

In addition to events and activities, a typical process involves decision points, 
that is, points in time when a decision is made that affects the way the process is 
executed. For example, as a result of the inspection, the site engineer may decide 
that the equipment should be returned or that the equipment should be accepted. 
This decision affects what happens later in the process. 

A process also involves a number of actors (human actors, organizations, or soft- 
ware systems acting on behalf of human actors or organizations), physical objects 
(equipment, materials, products, paper documents) and immaterial objects (elec- 
tronic documents and electronic records). For example, the equipment rental pro- 
cess involves three types of human actor (clerk, site engineer and works engineer) 
and two types of organizational actor (BuildIT and the equipment suppliers). The 
process also involves physical objects (the rented equipment), electronic documents 
(equipment rental requests, POs, invoices) and electronic records (equipment en- 
gagement records maintained in a spreadsheet). 

Finally, the execution of a process leads to one or several outcomes. For exam- 
ple, the equipment rental process leads to an equipment being used by BuildIT, 
as well as a payment being made to the equipment’s supplier. Ideally, an outcome 
should deliver value to the actors involved in the process, which in this example are 
BuildIT and the supplier. In some cases, this value is not achieved or is only partially 
achieved. For example, when an equipment is returned, no value is gained, neither 
by BuildIT nor by the supplier. This corresponds to a negative outcome, as opposed 
to a positive outcome that delivers value to the actors involved. 

Among the actors involved in a process, the one who consumes the output of the 
process plays a special role, namely the role of the customer. For example, in the 
above process, the customer is the site engineer, since it is the site engineer who 
puts the rented equipment to use. It is also the site engineer who will most likely 
be dissatisfied if the outcome of the process is unsatisfactory (negative outcome) or 
if the execution of the process is delayed. In this example, the customer is internal 
to BuildIT, meaning that the customer is an employee of the organization. In other 
processes, such as an order-to-cash process, the customer is external to the orga- 
nization. Sometimes, there are multiple customers in a process. For example, in a 
process for selling a house, there is a buyer, a seller, a real estate agent, one or mul- 
tiple mortgage providers, and at least one notary. The outcome of the process is a 
sales transaction. This outcome provides value both to the buyer who gets the house 
and to the seller who monetizes the house. Therefore, both the buyer and the seller 
can be seen as customers in this process, while the remaining actors provide various 
services. 


Exercise 1.1 Consider the following process for the admission of graduate students 
at a university. 
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In order to apply for admission, students first fill in an online form. Online applications are 
recorded in an information system to which all staff members involved in the admissions 
process have access to. After a student has submitted the online form, a PDF document is 
generated and the student is requested to download it, sign it, and send it by post together 
with the required documents, which include: 


e Certified copies of previous degree and academic transcripts. 
e Results of English language test. 
e Curriculum vitae. 


When these documents are received by the admissions office, an officer checks the com- 
pleteness of the documents. If any document is missing, an e-mail is sent to the student. The 
student has to send the missing documents by post. Assuming the application is complete, 
the admissions office sends the certified copies of the degrees to an academic recognition 
agency, which checks the degrees and gives an assessment of their validity and equivalence 
in terms of local education standards. This agency requires that all documents be sent to 
it by post, and all documents must be certified copies of the originals. The agency sends 
back its assessment to the university by post as well. Assuming the degree verification is 
successful, the English language test results are then checked online by an officer at the 
admissions office. If the validity of the English language test results cannot be verified, the 
application is rejected (such notifications of rejection are sent by e-mail). 

Once all documents of a given student have been validated, the admission office forwards 
these documents by internal mail to the corresponding academic committee responsible for 
deciding whether to offer admission or not. The committee makes its decision based on 
the academic transcripts and the CV. The committee meets once every 2 to 3 weeks and 
examines all applications that are ready for academic assessment at the time of the meeting. 
At the end of the committee meeting, the chair of the committee notifies the admissions 
office of the selection outcomes. This notification includes a list of admitted and rejected 
candidates. A few days later, the admission office notifies the outcome to each candidate 
via e-mail. Additionally, successful candidates are sent a confirmation letter by post. 


With respect to the above process, consider the following questions: 


. Who are the actors in this process? 

. Which actors can be considered to be the customer (or customers) in this process? 
. What value does the process deliver to its customer(s)? 

. What are the possible outcomes of this process? 


BRWN Re 


In light of the above, we define a business process as a collection of inter-related 
events, activities and decision points that involve a number of actors and objects, 
and that collectively lead to an outcome that is of value to at least one customer. 
Figure 1.1 depicts the ingredients of this definition and their relations. 

Armed with this definition of a business process, we define BPM as a body of 
methods, techniques and tools to discover, analyze, redesign, execute and monitor 
business processes. This definition reflects the fact that business processes are the 
focal point of BPM, and also the fact that BPM involves different phases and activ- 
ities in the lifecycle of business processes, as we will discuss later in this chapter. 

Other disciplines besides BPM deal with business processes in different ways as 
explained in the box “Related Disciplines”. One of the features commonly associ- 
ated to BPM is its emphasis on the use of process models throughout the lifecycle 
of business processes. Accordingly, process models are present in one way or an- 
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Fig. 1.1 Ingredients of a business process 


other in virtually all chapters of this book and two chapters are dedicated to process 
modeling. 

In any case, while it is useful to know that multiple disciplines share the aim of 
improving business processes, we should remain pragmatic and not pitch one disci- 
pline against the other as if they were competitors. Instead, we should embrace any 
technique that helps us to improve business processes, whether or not this technique 
is perceived as being part of the BPM discipline (in the strict sense) and regardless 
of whether or not the technique in question uses process models. 


RELATED DISCIPLINES 

BPM is by no means the only discipline that is concerned with improving the 
operational performance of organizations. Below, we briefly introduce some 
related disciplines and identify key relations and differences between these 
disciplines and BPM. 


Total Quality Management (TQM) is an approach that both historically 
preceded and inspired BPM. The focus of TQM is on continuously improv- 
ing and sustaining the quality of products, and by extension also of services. 
In this way, it is similar to BPM in its emphasis on the necessity of ongo- 
ing improvement efforts. But where TQM puts the emphasis on the products 
and services themselves, the view behind BPM is that the quality of prod- 
ucts and services can best be achieved by focusing on the improvement of the 
processes that create these products and services. It should be admitted that 
this view is somewhat controversial, as contemporary TQM adepts would 
rather see BPM as one of the various practices that are commonly found 
within a TQM program. Not so much a theoretical distinction but an empir- 
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ical one is that applications of TQM are primarily found in manufacturing 
domains—where the products are tangible—while BPM is more oriented to 
service organizations. 

Operations Management is a field concerned with managing the physical 
and technical functions of a firm or organization, particularly those relating 
to production and manufacturing. Probability theory, queuing theory, deci- 
sion analysis, mathematical modeling, and simulation are all important tech- 
niques for optimizing the efficiency of operations from this perspective. As 
will be discussed in Chap. 7, such techniques are also useful in the context 
of BPM initiatives. What is rather different between operations management 
and BPM is that operations management is generally concerned with con- 
trolling an existing process without necessarily changing it, while BPM is 
often concerned with making changes to an existing process in order to im- 
prove it. 

Lean is a management discipline that originates from the manufacturing in- 
dustry, in particular the engineering philosophy of Toyota. One of the main 
principles of Lean is the elimination of waste, i.e. activities that do not add 
value to the customer as we will discuss in Chap. 6. The customer orientation 
of Lean is similar to that of BPM and many of the principles behind Lean 
have been absorbed by BPM. In that sense, BPM can be seen as a more en- 
compassing discipline than Lean. Another difference is that BPM puts more 
emphasis on the use of information technology as a tool to improve business 
processes and to make them more consistent and repeatable. 

Six Sigma is another set of practices that originate from manufacturing, in 
particular from engineering and production practices at Motorola. The main 
characteristic of Six Sigma is its focus on the minimization of defects (er- 
rors). Six Sigma places a strong emphasis on measuring the output of pro- 
cesses or activities, especially in terms of quality. Six Sigma encourages 
managers to systematically compare the effects of improvement initiatives 
on the outputs. In practice, Six Sigma is not necessarily applied alone, but 
in conjunction with other approaches. In particular, a popular approach is to 
blend the philosophy of Lean with the techniques of Six Sigma, leading to 
an approach known as Lean Six Sigma. Nowadays, many of the techniques 
of Six Sigma are commonly applied in BPM as well. In Chap. 6, we will 
introduce a few business process analysis techniques that are shared by Six 
Sigma and BPM. 


In summary, we can say that BPM inherits from the continuous improve- 
ment philosophy of TQM, embraces the principles and techniques of opera- 
tions management, Lean and Six Sigma, and combines them with the capa- 
bilities offered by modern information technology, in order to optimally align 
business processes with the performance objectives of an organization. 
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1.3 Origins and History of BPM 


To better understand why organizations engage in BPM and what benefits it brings 
to them, it is worth looking at the reasons why BPM has emerged and evolved 
over time. Below we look into the drivers of the BPM discipline from a historical 
perspective. We start with the emergence of functional organizations, continue with 
the introduction of process thinking, towards the innovations and failures of business 
process re-engineering. This discussion provides the basis for the definition of the 
BPM lifecycle afterwards. 


1.3.1 The Functional Organization 


The key idea of BPM is to focus on processes when organizing and managing work 
in an organization. This idea may seem intuitive and straightforward at first glance. 
Indeed, if one is concerned with the quality of a particular product or service and 
the speed of its delivery to a customer, why not consider the very steps that are nec- 
essary to produce it? Even though intuitive, it took several evolutionary steps before 
this idea became integral part of the work structures of organizations. Figure 1.2 
provides an overview of some historical developments relevant to BPM. 

In prehistoric times, humans mostly supported themselves or the small groups 
they lived in by producing their own food, tools, and other items. In such early 
societies, the consumers and producers of a given good were often the same persons. 
In industrial terms, people carried out their own production processes. As a result, 
they had knowledge of how to produce many different things. In other words, they 
were generalists. 

In ancient times, in parallel with the rise of cities and city states, this work struc- 
ture based on generalists started to evolve towards what can be characterized as an 
intermediate level of specialism. People started to specialize in the art of delivering 
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one specific type of goods, such as pottery, or providing one particular type of ser- 
vices, such as lodging for travelers. This widespread development towards a higher 
level of specialism of the workforce culminated in the guilds of the craftsmen dur- 
ing the Middle Ages. These guilds were essentially groups of merchants and artisans 
concerned with the same economic activity, such as barbers, shoemakers, masons, 
surgeons, and sculptors. Workers in this time would have a good understanding of 
an entire process that they were involved in, but not so much about the processes 
that produced the goods or services they obtained from others. 

This higher degree of specialization of the medieval worker shifted further to- 
wards a form of pure specialization during the Second Industrial Revolution, be- 
tween the second half of the 19th century and the First World War. A name that is 
inseparably linked to it is that of Frederick W. Taylor (1856-1915), who proposed 
a set of principles known as scientific management. A key element in Taylor’s ap- 
proach was an extreme form of labor division. By meticulously studying labor activ- 
ities, such as the individual steps that were required to handle pig iron in steel mills, 
Taylor developed very specific work instructions for laborers. Laborers would only 
be involved with carrying out one of the many steps in the production process. Not 
only in industry, but also in administrative settings, such as government organiza- 
tions, the concept of division of labor became the most dominant form of organizing 
work. The upshot of this development was that workers became pure specialists who 
would be concerned with only a single part of one business process. 

A side-effect of the ideas of Taylor and his contemporaries was the emergence 
of an altogether new class of professionals, that of managers. After all, someone 
needed to oversee the productivity of groups of workers concerned with the same 
part of a production process. Managers were responsible for pinning down the pro- 
ductivity goals for individual workers and making sure that such goals were met. 
In contrast to the masters of the medieval guilds, who could only attain such a rank 
on the basis of a masterpiece produced by themselves, managers are not necessarily 
experts in carrying out the job they oversee. Their main interest is to optimize how 
a job is done with the resources under their supervision. 

After the emergence of managers, organizations became structured along the 
principles of labor division. A next and obvious challenge arose then: How to differ- 
entiate between the responsibilities of all these managers? The solution was to create 
functional units in which people with a similar focus on part of the production pro- 
cess were grouped together. These units were overseen by managers with different 
responsibilities. Moreover, the units and their managers were structured hierarchi- 
cally: for example, groups are under departments, departments are under business 
units, etc. What we see here is the root of the functional units that are familiar to us 
today when we think about organizations: purchasing, sales, warehousing, finance, 
marketing, human resource management, etc. 

The functional organization that emerged from the mindset of the Second In- 
dustrial Revolution, dominated the corporate landscape for the greatest part of the 
19th and 20th centuries. Towards the end of the 1980s, however, major American 
companies such as IBM, Ford, and Bell Atlantic (now Verizon) came to realize that 
their emphasis on functional optimization was creating inefficiencies in their op- 
erations that were affecting their competitiveness. Costly projects that introduced 
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Fig. 1.3. Purchasing process at Ford at the initial stage 


new IT systems or reorganized work within a functional department with the aim 
of improving its efficiency, were not notably helping these companies to become 
more competitive. It seemed as if customers remained oblivious to these efforts and 
continued to take their business elsewhere, for example to Japanese competitors. 


1.3.2 The Birth of Process Thinking 


One of the breakthrough events for the development of BPM was Ford’s acquisi- 
tion of a big financial stake in Mazda during the 1980s. When visiting Mazda’s 
plants, one of the things that observant Ford executives noticed was that units 
within Mazda seemed considerably understaffed in comparison with comparable 
units within Ford, yet operated normally. A famous case study illustrating this phe- 
nomenon, first narrated by Michael Hammer [26] and subsequently analyzed by 
many others, deals with Ford’s purchasing process. Figure 1.3 depicts the way pur- 
chasing was done within Ford at the time. 

Every purchase that Ford would make needed to go through the purchasing de- 
partment. On deciding that a particular quantity of products indeed had to be pur- 
chased, this department sent out an order to the vendor in question. It would also 
send a copy of that order to accounts payable. When the vendor followed up, the 
ordered goods would be delivered at Ford’s receiving warehouse. Along with the 
goods came a shipping notice, which was passed on to accounts payable. The ven- 
dor would also send out an invoice to accounts payable directly. 

Against this background, it becomes clear that the main task of accounts payable 
was to check the consistency between three different documents (purchase order 
copy, shipping notice, invoice), where each document consists of roughly 14 data 
items (type of product, quantity, price, etc.). Not surprisingly, various types of dis- 
crepancy were discovered every day and sorting out these discrepancies occupied 
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several hundred people within Ford. In contrast, at Mazda only five people worked 
at this department, while Mazda was not 100 times smaller than Ford in any rele- 
vant measure. Fundamentally, the problem is that Ford was detecting and resolving 
with problems (in this case discrepancies) one by one, while Mazda instead was 
avoiding the discrepancies in the first place. After a more detailed comparison with 
Mazda, Ford carried out several changes in its own purchasing process, leading to 
the redesigned process depicted in Fig. 1.4. 

First of all, a central database was developed to store information on purchases. 
This database was used by the purchasing department to store all the information 
on purchase orders. This database replaced one of the original paper streams. Sec- 
ondly, new computer terminals were installed at the warehouse department which 
gave direct access to that database. When goods arrived, the warehouse personnel 
could immediately check whether the delivery actually matched what was originally 
purchased. If this was not the case, the goods were simply not accepted: this put the 
onus on the vendor to ensure that what was delivered was what was requested and 
nothing else. In cases where a match was found between the delivered goods and 
the recorded purchase order, the acceptance of the goods was registered. So, the 
only thing left to do for accounts payable was to pay what was agreed upon in the 
original purchase order. Following this new set-up, Ford managed to bring down 
their workforce in accounts payable from roughly 500 people down to 120 people 
(a 76 % reduction). 


Exercise 1.2 Consider the purchasing process at Ford. 


1. Who are the actors in this process? 

2. Which actors can be considered to be the customer (or customers) in this process? 
3. What value does the process deliver to its customer(s)? 

4. What are the possible outcomes of this process? 
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A key element in this case study is that a problematic performance issue (i.e. an 
excessive amount of time and resources spent on checking documents in accounts 
payable) is approached by considering an entire process. In this case, the accounts 
payable department plays an important role in the overall purchasing process, but 
the process also involves tasks by staff at the purchasing department, the warehouse, 
and by the vendor. Regardless of these barriers, changes are made across the process 
and these changes are multi-pronged: They include informational changes (informa- 
tion exchanges), technological changes (database, terminals), and structural changes 
(checks, policies). 

This characteristic view on how to look at organizational performance was put 
forward in a seminal article by Tom Davenport and James Short [11]. In this article, 
the authors urged managers to look at entire processes when trying to improve the 
operations of their business, instead of looking at one particular task or business 
function. Various cases were discussed where indeed this particular approach proved 
to be successful. In the same paper, the important role of IT was emphasized as an 
enabler to come up with a redesign of existing business processes. Indeed, when 
looking at the Ford—Mazda example it would seem difficult to change the traditional 
procedure without the specific qualities of IT, which in general allows access to 
information in a way that is independent of time and place. 


1.3.3 The Rise and Fall of BPR 


The work by Davenport and Short, as well as that of others, triggered the emergence 
and widespread adoption of a management concept that was referred to as Business 
Process Redesign or Business Process Re-engineering, often conveniently abbre- 
viated to BPR. Numerous white papers, articles, and books appeared on the topic 
throughout the 1990s and companies all over the world assembled BPR teams to 
review and redesign their processes. 

The enthusiasm for BPR faded down, however, by the late 1990s. Many compa- 
nies terminated their BPR projects and stopped supporting further BPR initiatives. 
What had happened? In a retrospective analysis, a number of factors can be distin- 
guished: 


1. Concept misuse: In some organizations, about every change program or improve- 
ment project was labeled BPR even when business processes were not the core of 
these projects. During the 1990s, many corporations initiated considerable reduc- 
tions of their workforce (downsizing) which, since they were often packaged as 
process redesign projects, triggered intense resentment among operational staff 
and middle management against BPR. After all, it was not at all clear that oper- 
ational improvement was really driving such initiatives. 

2. Over-radicalism: Some early proponents of BPR, including Michael Hammer, 
emphasized from the very start that redesign had to be radical, in the sense that 
a new design for a business process had to overhaul the way the process was 
initially organized. A telling indication is one of Michael Hammer’s early papers 
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on this subject which bore the subtitle: “Don’t automate, Obliterate”. While a 
radical approach may be justified in some situations, it is clear that many other 
situations require a much more gradual (incremental) approach. 

3. Support immaturity: Even in projects that were process-centered from the start 
and took a more gradual approach to improving the business process in question, 
people ran into the problem that the necessary tools and technologies to imple- 
ment such a new design were not available or sufficiently powerful. One particu- 
lar issue centered around the fact that much logic on how processes had to unfold 
were hard-coded in the supporting IT applications of the time. Understandably, 
people grew frustrated when they noted that their efforts on redesigning a process 
were thwarted by a rigid infrastructure. 


Subsequently, two key events revived some of the ideas behind BPR and laid 
the foundation for the emergence of BPM. First of all, empirical studies appeared 
showing that organizations that were process-oriented—that is, organizations that 
sought to improve processes as a basis for gaining efficiency and satisfying their 
customers—factually did better than non-process-oriented organizations. While the 
initial BPR guru’s provided compelling case studies, such as the one on Ford— 
Mazda, it remained unclear to many whether these were exceptions rather than the 
tule. In one of the first empirical studies on this topic, Kevin McCormack [49] in- 
vestigated a sample of 100 US manufacturing organizations and found that process- 
oriented organizations showed better overall performance, tended to have a bet- 
ter esprit de corps in the workplace, and suffered less from inter-functional con- 
flicts. Follow-up studies confirmed this picture, giving renewed credibility to pro- 
cess thinking. 

A second important development was technological in nature. Different types of 
IT system emerged, most notably Enterprise Resource Planning (ERP) systems and 
Workflow Management Systems (WfMSs). ERP systems are essentially systems 
that store all data related to the business operations of a company in a consistent 
manner, so that all stakeholders who need access to these data can gain such access. 
This idea of a single shared and centralized database enables the optimization of 
information usage and information exchanges, which is a key enabler of process 
improvement (cf. Chap. 8).! Wf£MSs on the other hand are systems that distribute 
work to various actors in a company on the basis of process models. By doing so, 
a WfMS make it easier to implement changes to business processes (e.g. to change 
the order in which steps are performed) because the changes made in the process 
model can be put into execution with relative ease, compared to the situation where 
the rules for executing the process are hard-coded inside complex software systems 
and buried inside tens of thousands of lines of code. Also, a WfMS very closely 
supports the idea of working in a process-centered manner. 


'In reality, ERP systems are much more than a shared database. They also incorporate numerous 
modules to support typical functions of an organization such as accounting, inventory management, 
production planning, logistics, etc. However, from the perspective of process improvement, the 
shared database concept behind ERP systems is a major enabler. 


14 1 Introduction to Business Process Management 


Changes in goals and plans 


Plan and Organize Process Monitor and Control Process 
Set goals and exceptations, Monitor process, 
Establish plans and budget, Reinforce success, 
Provide resources and staff, Definition of goals and measures Diagnose deviations, 


Implement process Take corrective actions 


Feedback 
Expectations, Data about 
Plans, results and 
Resources measures 


Process Execution 


Inputs Results 


Fig. 1.5 Job functions of a manager responsible for a process (a.k.a. process owner) 


Originally, WfMSs were concerned mainly with routing work between human 
actors. Later on, these systems were little by little extended with modules to monitor 
and analyze the execution of business processes. In parallel, the emergence of Web 
services made it easier to connect a WfMS with other systems, in particular ERP 
systems. As WfMSs became more sophisticated and better integrated with other 
enterprise systems, they became known as Business Process Management Systems 
(BPMSs). The functionality of BPMSs and their role in the automation of business 
processes will be discussed in Chap. 9. 

The above historical view suggests that BPM is a revival of BPR, as indeed BPM 
adopts the process-centered view on organizations. Some caution is due though 
when BPR and BPM are being equated. The relation is much better understood 
on the basis of Fig. 1.5. 

This figure shows that a manager that is responsible for a business process—also 
called the process owner—is concerned with planning and organizing the process on 
the one hand and monitoring the process on the other. The figure allows us to explain 
the differences in scope between BPR and BPM. While both approaches take the 
business process as a starting point, BPR is primarily concerned with planning and 
organizing the process. By contrast, BPM provides concepts, methods, techniques, 
and tools that cover all aspects of managing a process—plan, organize, monitor, 
control—as well as its actual execution. In other words, BPR should be seen as a 
subset of techniques that can be used in the context of BPM. 

This discussion highlights that BPM encompasses the entire lifecycle of busi- 
ness processes. Accordingly, the next section provides an overview of the concepts, 
methods, techniques, and tools that compose the BPM discipline through the lens of 
the BPM lifecycle. This lens provides a structured view of how a given process can 
be managed. 
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1.4 The BPM Lifecycle 


In general, the first question that a team embarking on a BPM initiative needs to 
clarify is “what business processes are we intending to improve’? Right at the outset 
and before the possibility of applying BPM is put on the table, there will probably 
already be an idea of what operational problems the team has to address and what 
business processes are posing those operational problems. In other words, the team 
will not start from scratch. For example, if the problem is that site engineers com- 
plain that their job is being hampered by difficulties in securing construction equip- 
ment when needed, and knowing that this equipment is to a large extent rented, it 
is clear that this problem should be addressed by looking at the equipment rental 
process. Still, one has to delimit this process. In particular, one has to answer ques- 
tions such as: Does the process start right from the moment when rental suppliers 
are selected? Does it end when the rented equipment is delivered to the construction 
site or does it end when the equipment is returned back to the supplier, or does it 
continue until the fee for equipment rental has been paid to the supplier? 

These questions might be easy or hard to answer depending on how much pro- 
cess thinking has taken place in the organization beforehand. If the organization has 
engaged in BPM initiatives before, it is likely that an inventory of business pro- 
cesses is available and that the scope of these processes has been defined, at least to 
some extent. In organizations that have not engaged in BPM before, the BPM team 
has to start by at least identifying the processes that are relevant to the problem on 
the table, delimiting the scope of these processes, and identifying relations between 
these processes, such as for example part-of relations (i.e. one process being part of 
another process). This initial phase of a BPM initiative is termed process identifi- 
cation. This phase leads to a so-called process architecture, which typically takes 
the form of a collection of processes and links between these processes representing 
different types of relation. 

In general, the purpose of engaging in a BPM initiative is to ensure that the busi- 
ness processes covered by the BPM initiative lead to consistently positive outcomes 
and deliver maximum value to the organization in servicing its clients. Measuring 
the value delivered by a process is a crucial step in BPM. As renowned software en- 
gineer, Tom DeMarco, once famously put it: “You can’t control what you can’t mea- 
sure’. So before starting to analyze any process in detail, it is important to clearly 
define the process performance measures (also called process performance metrics) 
that will be used to determine whether a process is in “good shape” or in “bad 
shape”’. 

Cost-related measures are a recurrent class of measures in the context of BPM. 
For example, coming back to the equipment rental process, a possible performance 
measure is the total cost of all equipment rented by BuildIT per time interval (e.g. 
per month). Another broad and recurrent class of measures are those related to time. 
An example is the average amount of time elapsed between the moment an equip- 
ment rental request is submitted by a site engineer and the delivery of the equipment 
to the construction site. This measure is generally called cycle time. Finally, a third 
class of recurrent measures are those related to quality, and specifically error rates. 
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Error rate is the percentage of times that an execution of the process ends up in a 
negative outcome. In the case of the equipment rental process, one such measure 
is the number of pieces of equipment returned because they are unsuitable, or due 
to defects in the delivered equipment. The identification of such performance mea- 
sures (and associated performance objectives) is crucial in any BPM initiative. This 
identification is generally seen as part of the process identification phase, although 
in some cases it may be postponed until later phases. 


Exercise 1.3 Consider the student admission process described in Exercise 1.1. 
Taking the perspective of the customer, identify at least two performance measures 
that can be attached to this process. 


Once a BPM team has identified which processes they are dealing with and which 
performance measures should be used, the next phase for the team is to understand 
the business process in detail. We call this phase process discovery. Typically, one of 
the outcomes of this phase is one or several as-is process models. These as-is pro- 
cess models should reflect the understanding that people in the organization have 
about how work is done. Process models are meant to facilitate communication be- 
tween stakeholders involved in a BPM initiative. Therefore, they have to be easy 
to understand. In principle, we could model a business process by means of tex- 
tual descriptions, like the textual description in Example 1.1. However, such textual 
descriptions are cumbersome to read and easy to misinterpret because of the ambi- 
guity inherent in free-form text. This is why it is common practice to use diagrams 
in order to model business processes. Diagrams allow us to more easily comprehend 
the process. Also, if the diagram is made using a notation that is understood by all 
stakeholders, there is less room for any misunderstanding. Note that these diagrams 
may still be complemented with textual descriptions in fact it is common to see 
analysts documenting a process using a combination of diagrams and text. 

There are many languages for modeling business processes diagrammatically. 
Perhaps one of the oldest ones are flowcharts. In their most basic form, flowcharts 
consist of rectangles, representing activities, and diamonds, representing points in 
the process where a decision is made. More generally, we can say that regardless of 
the specific notation used, a diagrammatic process model typically consists of two 
types of node: activity nodes and control nodes. Activity nodes describe units of 
work that may be performed by humans or software applications, or a combination 
thereof. Control nodes capture the flow of execution between activities. Although 
not all process modeling languages support it, a third important type of element 
in process models are event nodes. An event node tells us that something may or 
must happen, within the process or in the environment of the process, that requires a 
reaction, like for example the arrival of a message from a customer asking to cancel 
their purchase order. Other types of node may appear in a process model, but we can 
say that activity nodes, event nodes and control nodes are the most basic ones. 

Several extensions of flowcharts exist, like cross-organizational flowcharts, 
where the flowchart is divided into so-called swimlanes that denote different organi- 
zational units (e.g. different departments in a company). If you are familiar with the 
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Fig. 1.6 Process model for an initial fragment of the equipment rental process 


Unified Modeling Language (UML), you probably will have come across UML Ac- 
tivity Diagrams. At their core, UML Activity Diagrams are cross-organizational 
flowcharts. However, UML Activity Diagrams go beyond cross-organizational 
flowcharts by providing symbols to capture data objects, signals and parallelism 
among other aspects. Yet another language for process modeling are Event-driven 
Process Chains (EPCs). EPCs have some similarities with flowcharts but they differ 
from flowcharts in that they treat events as first-class citizens. Other languages used 
for process modeling include data-flow diagrams and [DEF3, just to name two. 

It would be mind-boggling to try to learn all these languages at once. Fortunately, 
nowadays there is a widely used standard for process modeling, namely the Business 
Process Model and Notation (BPMN). The latest version of BPMN is BPMN 2.0. 
It was released as a standard by the Object Management Group (OMG) in 2011. 
In BPMN, activities are represented as rounded rectangles. Control nodes (called 
gateways) are represented using diamond shapes. Activities and control nodes are 
connected by means of arcs (called flows) that determine the order in which the pro- 
cess is executed. Figure 1.6 provides a model representing an initial fragment of the 
equipment rental process, up to the point where the works engineer accepts or rejects 
the equipment rental request. This process model shows two decision points. In the 
first one, the process takes one of two paths depending on whether the equipment 
is available or not. In the second, the equipment rental request is either approved or 
rejected. The model also shows the process participants involved in this fragment 
of the process, namely the site engineer, the clerk and the works engineer. Each of 
these participants is shown as a separate /ane containing the activities performed by 
the participant in question. 
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The process model in Fig. 1.6 is captured at a high level of abstraction. At best, it 
can serve to give to an external person a summary of what happens in this process. 
In some cases, however, the model needs more details for it to be useful. Which 
additional details should be included in a process model depends on the purpose. 
Oftentimes, process models are intended to serve as documentation of the way 
an organization works. In this case, the key characteristics of process models are 
simplicity and understandability. Accordingly, additional text annotations might be 
added to the process model to clarify the meaning of certain activities or events, but 
beyond such annotations, not much additional detail would be added. In other cases, 
process models are intended to be analyzed in detail, for example in order to mea- 
sure process performance. In this case, further details may be required such as how 
much time each task takes (on average). Finally, in a few cases, process models are 
intended to be deployed into a BPMS for the purpose of coordinating the execution 
of the process (cf. Sect. 1.3.3). In the latter case, the model needs to be extended 
with a significant amount of details regarding the inputs and outputs of the process 
and each its activities. 

Having understood the as-is process in detail, the next step is to identify and 
analyze the issues in this process. One potential issue in BuildIT’s equipment rental 
process is that the cycle time is too high. As a result, site engineers do not manage to 
get the required equipment on time. This may cause delays in various construction 
tasks, which may ripple down into delays in the construction projects. In order to 
analyze these issues, an analyst would need to collect information about the time 
spent in each task of the process, including both the amount of time that process 
participants spend actually doing work and the amount of idle time, meaning the 
amount of time when the equipment request is blocked, waiting for something to 
happen. This idle time is also called waiting time. Also, the analyst would need to 
gather information regarding the amount of rework that takes place in the process. 
Here, rework means that one or several tasks are repeated because something went 
wrong. For example, when the clerk identifies a suitable piece of equipment in a 
supplier’s catalog, but later finds out that the piece of equipment is not available 
on the required dates, the clerk might need to search again for an alternative piece 
of equipment from another supplier. Valuable time is spent by the clerk going back 
and forth between consulting the catalogs and contacting the suppliers to check the 
availability of plants. In order to analyze this issue, the analyst would need to find 
out in what percentage of cases the availability check fails and thus how often the 
clerk needs to do some rework in order to identify alternative pieces of equipment 
and check for their availability. Given this information, a process analyst can employ 
various techniques to be discussed throughout this book, in order to trace down the 
cause(s) of long cycle times and to identify ways of changing the process in order 
to reduce the cycle time. 

Another potential issue in BuildIT’s equipment rental process is that sometimes 
the equipment delivered at the construction site is unsuitable, and the site engineer 
has to reject it. This is an example of a negative outcome. To analyze this issue, 
an analyst would need to find out how often such negative outcomes are occurring. 
Secondly, the analysts would need to obtain information that would allow them 
to understand why such negative outcomes are happening. In other words, where 
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did things go wrong in the first place? Sometimes, this negative outcome might 
stem from miscommunication, for example between the site engineer and the clerk. 
Otherwise it might come from inaccurate data (e.g. errors in the description of the 
equipment) or from an error on the supplier’s side. Only by identifying, classifying 
and ultimately understanding the main causes of such negative outcomes can an 
analyst find out what would be the most suitable way of addressing this issue. The 
identification and assessment of issues and opportunities for process improvement 
is hereby called the process analysis phase. 

We observe that the two issues discussed above are tightly related to performance 
measures. For example, the first issue above is tied to cycle time and waiting time, 
both of which are typical performance measures of a process. Similarly, the second 
issue is tied to the “percentage of equipment rejections”, which is essentially an error 
rate—another typical performance measure. Thus, assessing the issues of a process 
often goes hand-in-hand with measuring the current state of the process with respect 
to certain performance measures. 


Exercise 1.4 Consider again the student admission process described in Exer- 
cise 1.1. Taking the perspective of the customer, think of at least two issues that 
this process might have. 


Once issues in a process have been analyzed and possibly quantified, the next 
phase is to identify and analyze potential remedies for these issues. At this point, the 
analyst will consider multiple possible options for addressing a problem. In doing 
so, the analyst needs to keep in mind that a change in a process to address one 
issue may potentially cause other issues down the road. For example, in order to 
speed-up the equipment rental process, one might think of removing the approval 
steps involving the works engineer. If pushed to the extreme, however, this change 
would mean that the rented equipment might sometimes not be optimal since the 
works engineer viewpoint is not taken into account. The works engineer has a global 
view on the construction projects and may be able to propose alternative ways of 
addressing the equipment needs of a construction project in a more effective manner. 

Changing a process is not as easy as it sounds. People are used to work in a cer- 
tain way and might resist changes. Furthermore, if the change implies modifying the 
information system(s) underpinning the process, the change may be costly or may 
require changes not only in the organization that coordinates the process, but also in 
other organizations. For example, one way to eliminate the rework that the clerk has 
to do when checking for availability of equipment, would be that the suppliers pro- 
vide information regarding the availability of plants. This way, the clerk would use 
the same interface to search for suitable equipment and to check the availability of 
the equipment for the required period of time. However, this change in the process 
would require that the suppliers change their information system, so that their sys- 
tem exposes up-to-date equipment availability information to BuildIT. This change 
is at least partially outside the control of BuildIT. Assuming that suppliers would 
be able to make such changes, a more radical solution that could be considered 
would be to provide mobile devices and Internet connection to the site engineers, so 
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that they can consult the catalog of equipment (including availability information) 
anytime and anywhere. This way, the clerk would not need to be involved in the 
process during the equipment search phase, therefore avoiding miscommunications 
between the site engineer and the clerk. Whether or not this more radical change is 
viable would require an in-depth analysis of the cost of changing the process in this 
way versus the benefits that such change would provide. 


Exercise 1.5 Given the issues in the admissions process identified in Exercise 1.4, 
what possible changes do you think could be made to this process in order to address 
these issues? 


Equipped with an understanding of one or several issues in a process and a can- 
didate set of potential remedies, analysts can propose a redesigned version of the 
process, in other words a to-be process which would address the issues identified 
in the as-is process. This to-be process is the main output of the process redesign 
phase. Here, it is important to keep in mind that analysis and redesign are intricately 
related. There may be multiple redesign options and each of these options needs to 
be analyzed, so that an informed choice can be made as to which option should be 
chosen. 

Once redesigned, the necessary changes in the ways of working and the IT sys- 
tems of the organization should be implemented so that the to-be process can even- 
tually be put into execution. This phase is called process implementation. In the 
case of the equipment rental process, the process implementation phase would mean 
putting in place an information system to record and to track equipment rental re- 
quests, POs associated to approved requests and invoices associated to these POs. 
Deploying such an information system means not only developing the IT compo- 
nents of this system. It would also relate to training the process participants so that 
they perform their work in the spirit of the redesigned process and make the best use 
of the IT components of the system. 

More generally, process implementation may involve two complementary facets: 
organizational change management and process automation. Organizational change 
management refers to the set of activities required to change the way of working of 
all participants involved in the process. These activities include: 


e Explaining the changes to the process participants to the point that they under- 
stand both what changes are being introduced and why these changes are benefi- 
cial to the company. 

e Putting in place a change management plan so that stakeholders know when will 
the changes be put into effect and what transitional arrangements will be em- 
ployed to address problems during the transition to the to-be process. 

e Training users to the new way of working and monitoring the changes in order to 
ensure a smooth transition to the to-be process. 


On the other hand, process automation involves the configuration or implementa- 
tion of an IT system (or the re-configuration of an existing IT system) to support the 
“to-be” process. This system should support process participants in the performance 
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Fig. 1.7. BPM lifecycle 
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of the tasks of the process. This may include assigning tasks to process participants, 
helping process participants to prioritize their work, providing process participants 
with the information they need to perform a task, and performing automated cross- 
checks and other automated tasks where possible. There are several ways to im- 
plement such an IT system. This book focuses on one particular approach, which 
consists of extending the to-be process model obtained from the process redesign 
phase in order to make it executable by a BPMS (cf. Sect. 1.3.3). 

Over time, some adjustments might be required because the implemented busi- 
ness process does not meet expectations. To this end, the process needs to be moni- 
tored and analysts ought to scrutinize the data collected by monitoring the process in 
order to identify needed adjustments to better control the execution of the process. 
These activities are encompassed by the process monitoring and controlling phase. 
This phase is important because addressing one or a handful of issues in a process 
is not the end of the story. Instead, managing a process requires a continuous effort. 
Lack of continuous monitoring and improvement of a process leads to degradation. 
As Michael Hammer once put it: “every good process eventually becomes a bad pro- 
cess”, unless continuously adapted and improved to keep up with the ever-changing 
landscape of customer needs, technology and competition. This is why the phases 
in the BPM lifecycle should be seen as being circular: the output of monitoring and 
controlling feeds back into the discovery, analysis and redesign phases. 

To sum up, we can view BPM as continuous cycle comprising the following 
phases (see Fig. 1.7): 


Process 
monitoring and 
controlling 


Executable 
process 
model 


Process 


implementation 


To-be process 
model 


e Process identification. In this phase, a business problem is posed, processes rele- 
vant to the problem being addressed are identified, delimited and related to each 
other. The outcome of process identification is a new or updated process archi- 
tecture that provides an overall view of the processes in an organization and their 
relationships. In some cases, process identification is done in parallel with per- 
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formance measure identification. In this book, however, we will associate perfor- 
mance measure identification with the process analysis phase, given that perfor- 
mance measures are often used for process analysis. 

e Process discovery (also called as-is process modeling). Here, the current state 
of each of the relevant processes is documented, typically in the form of one or 
several as-is process models.” 

e Process analysis. In this phase, issues associated to the as-is process are identi- 
fied, documented and whenever possible quantified using performance measures. 
The output of this phase is a structured collection of issues. These issues are typ- 
ically prioritized in terms of their impact, and sometimes also in terms of the 
estimated effort required to resolve them. 

e Process redesign (also called process improvement). The goal of this phase is to 
identify changes to the process that would help to address the issues identified 
in the previous phase and allow the organization to meet its performance objec- 
tives. To this end, multiple change options are analyzed and compared in terms of 
the chosen performance measures. This entails that process redesign and process 
analysis go hand-in-hand: As new change options are proposed, they are ana- 
lyzed using process analysis techniques. Eventually, the most promising change 
options are combined, leading to a redesigned process. The output of this phase 
is typically a to-be process model, which serves as a basis for the next phase. 

e Process implementation. In this phase, the changes required to move from the 
as-is process to the to-be process are prepared and performed. Process imple- 
mentation covers two aspects: organizational change management and process 
automation. Organizational change management refers to the set of activities re- 
quired to change the way of working of all participants involved in the process. 
Process automation on the other hand refers to the development and deployment 
of IT systems (or enhanced versions of existing IT systems) that support the to-be 
process. In this book, our focus with respect to process implementation is on pro- 
cess automation, as organizational change management is an altogether separate 
field. More specifically, the book presents one approach to process automation 
wherein an executable process model is derived from the to-be process model 
and this executable model is deployed in a BPMS. 

e Process monitoring and controlling. Once the redesigned process is running, rel- 
evant data are collected and analyzed to determine how well is the process per- 
forming with respect to its performance measures and performance objectives. 
Bottlenecks, recurrent errors or deviations with respect to the intended behavior 
are identified and corrective actions are undertaken. New issues may then arise, in 
the same or in other processes, requiring the cycle to be repeated on a continuous 
basis. 


>This phase is also called process design in the literature. However, process discovery is arguably a 
more appropriate term since the process already exists, at least implicitly in the heads of the actors 
who perform it. The goal of this phase is generally to discover the process rather than to design it. 
In rare cases (e.g. new companies) no process is yet in place so the discovery and analysis phases 
are not required and the process has to be designed for the first time rather than redesigned. 
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The BPM lifecycle helps to understand the role of technology in BPM. Tech- 
nology in general, and especially Information Technology (IT), is a key instrument 
to improve business processes. Not surprisingly, IT specialists such as system engi- 
neers often play a significant role in BPM initiatives. However, to achieve maximum 
efficacy, system engineers need to be aware that technology is just one instrument 
for managing and executing processes. System engineers need to work together with 
process analysts in order to understand what the main issues affecting a given pro- 
cess, and how to best address these issues, be it by means of automation or by other 
means. As a renowned technology businessman, Bill Gates, once famously put it: 
“The first rule in any technology used in a business is that automation applied to 
an efficient operation will magnify the efficiency. The second is that automation 
applied to an inefficient operation will magnify the inefficiency”. This means that 
learning how to design and improve processes—and not only how to build an IT 
system to automate a narrow part of a business process—is a fundamental skill that 
should be in the hands of any IT graduate. Reciprocally, business graduates need 
to understand how technology, and particularly IT, can be used to optimize the ex- 
ecution of business processes. This book aims at bridging these two viewpoints by 
presenting an integrated viewpoint covering the whole BPM lifecycle. 

A complementary viewpoint on the BPM lifecycle is given by the box “Stake- 
holders in the BPM lifecycle”. This box summarizes the roles in a company that 
are directly or indirectly involved in BPM initiatives.* The list of roles described in 
the box highlights the fact that BPM is inter-disciplinary. A typical BPM initiative 
involves managers at different levels in the organization, administrative and field 
workers (called process participants in the box), business and system analysts and 
IT teams. Accordingly, the book aims at giving a balanced view of techniques both 
from management science and IT, as they pertain to BPM. 


STAKEHOLDERS IN THE BPM LIFECYCLE 

There are different stakeholders involved with a business process throughout 
its lifecycle. Among them we can distinguish the following individuals and 
groups. 


e Management Team. Depending on how the management of a company is 
organized, one might find the following positions. The Chief Executive Of- 
ficer (CEO) is responsible for the overall business success of the company. 
The Chief Operations Officer (COO) is responsible for defining the way 
operations are set-up. In some companies, the COO is also responsible for 
process performance, while in other companies, there is a dedicated posi- 


3The role of the customer is not listed in the box as this role is already discussed in previous 
sections. 
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tion of Chief Process Officer (CPO) for this purpose. The Chief Information 
Officer (CIO) is responsible for the efficient and effective operation of the 
information system infrastructure. In some organizations, process redesign 
projects are driven by the CIO. The Chief Financial Officer (CFO) is re- 
sponsible for the overall financial performance of the company. The CFO 
may also be responsible for certain business processes, particularly those 
that have a direct impact on financial performance. Other management po- 
sitions that have a stake in the lifecycle of processes include the Human 
Resources (HR) director. The HR director and their team play a key role in 
processes that involve significant numbers of process participants. In any 
case, the management team is responsible for overseeing all processes, ini- 
tiating process redesign initiatives, and providing resources and strategic 
guidance to stakeholders involved in all phases of the business process life- 
cycle. 

Process Owners. A process owner is responsible for the efficient and effec- 
tive operation of a given process. As discussed in the context of Fig. 1.5, 
a process owner is responsible on the one hand for planning and organizing, 
and on the other hand for monitoring and controlling the process. In their 
planning and organizing role, the process owner is responsible for defining 
performance measures and objectives as well as initiating and leading im- 
provement projects related to their process. They are also responsible for 
securing resources so that the process runs smoothly on a daily basis. In 
their monitoring and controlling role, process owners are responsible for 
ensuring that the performance objectives of the process are met and taking 
corrective actions in case they are not met. Process owners also provide 
guidance to process participants on how to resolve exceptions and errors 
that occur during the execution of the process. Thus, the process owner is 
involved in process modeling, analysis, redesign, implementation and mon- 
itoring. Note that the same individual could well be responsible for multi- 
ple processes. For example, in a small company, a single manager might 
be responsible both for the company’s order-to-cash process and for the 
after-sales customer service process. 

Process Participants. Process participants are human actors who perform 
the activities of a business process on a day-to-day basis. They conduct 
routine work according to the standards and guidelines of the company. 
Process participants are coordinated by the process owner, who is respon- 
sible to deal with non-routine aspects of the process. Process participants 
are also involved as domain experts during process discovery and process 
analysis. They support redesign activities and implementation efforts. 
Process Analysts. Process analysts conduct process identification, discov- 
ery (in particular modeling), analysis and redesign activities. They coor- 
dinate process implementation as well as process monitoring and control- 
ling. They report to management and process owners and closely interact 
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with process participants. Process analyst typically have one of two back- 
grounds. Process analysts concerned with organizational requirements, per- 
formance, and change management have a business background. Mean- 
while, process analysts concerned with process automation have an IT 
background. 

e System Engineers. System engineers are involved in process redesign and 
implementation. They interact with process analysts to capture system re- 
quirements. They translate requirements into a system design and they are 
responsible for the implementation, testing and deployment of this system. 
System engineers also liaise with the process owner and process partici- 
pants to ensure that the developed system supports their work in an effec- 
tive manner. Oftentimes, system implementation, testing and deployment 
are outsourced to external providers, in which case the system engineering 
team will at least partially consist of contractors. 

e The BPM Group (also called BPM Centre of Excellence). Large organiza- 
tions that have been engaged in BPM for several years would normally have 
accumulated valuable knowledge on how to plan and execute BPM projects 
as well as substantial amounts of process documentation. The BPM Group 
is responsible for preserving this knowledge and documentation and ensur- 
ing that they are used to meet the organization’s strategic goals. Specifi- 
cally, the BPM group is responsible for maintaining the process architec- 
ture, prioritizing process redesign projects, giving support to the process 
owners and process analysts, and ensuring that the process documentation 
is maintained in a consistent manner and that the process monitoring sys- 
tems are working effectively. In other words, the BPM group is responsible 
for maintaining a BPM culture and ensuring that this BPM culture is sup- 
porting the strategic goals of the organization. Not all organizations have a 
dedicated BPM Group. BPM Groups are most common in large organiza- 
tions with years of BPM experience. 


In the rest of the book, we will dive consecutively into each of the phases of the 
BPM lifecycle. Chapter 2 deals with the process identification phase. Chapters 3-4 
provide an introduction to process modeling, which serves as background for sub- 
sequent phases in the BPM lifecycle. Chapter 5 deals with the process discovery 
phase. Chapters 6—7 present a number of process analysis techniques. We classify 
these techniques into qualitative (Chap. 6) and quantitative (Chap. 7) ones. A quan- 
titative technique is one that takes raw data or measurements as input (e.g. perfor- 
mance measures at the level of tasks) and produces aggregated measurements and 
quantitative summaries as output. On the other hand, a qualitative technique involves 
human judgment, for example in order to classify tasks or issues according to sub- 
jective criteria. Note that qualitative techniques may involve quantitative assessment 
in addition to human judgment, as these two sources of insights often serve comple- 
mentary purposes. Next, Chap. 8 gives an overview of process redesign techniques, 
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while Chap. 9 discusses process implementation with a focus on automation aspects. 
Finally, Chap. 10 introduces process intelligence tools and techniques, which form 
the backbone of modern process monitoring practices. 


1.5 Recap 


We should retain from this chapter that a process is a collection of events, activities 
and decisions that collectively lead to an outcome that brings value to an organi- 
zation’s customers. Every organization has processes. Understanding and managing 
these processes in order to ensure that they consistently produce value is a key ingre- 
dient for the effectiveness and competitiveness of organizations. Through its focus 
on processes, organizations are managing those assets that are most important to 
serve their customers well. 

If we wanted to capture BPM in a nutshell, we could say that BPM is a body 
of principles, methods and tools to design, analyze, execute and monitor business 
processes. We have also seen that process models and performance measures can be 
seen as foundational pillars for managing processes. It is on top of them that much 
of the art and science of BPM builds upon. The provided definition encompasses 
the main phases of the BPM lifecycle and the various related disciplines that com- 
plement BPM, such as Lean, Six Sigma and Total Quality Management. The aim of 
this chapter was to give a “sneak peek” of the activities and stakeholders involved 
in each of these phases. The rest of the book aims to shed light onto many of the 
principles and methods that are used in each of these phases. 


1.6 Solutions to Exercises 


Solution 1.1 


1. Admissions officer, applicant, academic recognition agency and academic com- 
mittee. The admissions office as an organizational unit can also be recognized as 
a separate actor. 

2. The applicant. 

3. One can argue that the value that the process provides to the applicant is the 
assessment of the application and the subsequent decision to accept or reject. In 
this case, the process delivers value both if the applicant is accepted or rejected, 
provided that the application is processed in due order. Another viewpoint would 
be to say that the process only gives value to the applicant only if the applicant 
is accepted, and not if the applicant is rejected. Arguments can be put forward in 
favor of either of these two viewpoints. 

4. Applicant rejected due to incomplete documents; Applicant rejected due to En- 
glish language test results; Applicant rejected due to assessment of academic 
recognition agency; Applicant rejected due to academic committee decision; 
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Applicant accepted. A more in-depth analysis could reveal other possible out- 
comes such as “Application withdrawn by applicant” or “Applicant condition- 
ally accepted subject to providing additional documents”. However, there are not 
enough elements in the description of the process to determine if these latter 
outcomes are possible. 


Solution 1.2 


i 


Ze 
. The value that the process provides to the unit with a purchasing need is the 


The unit with a purchasing need, purchasing department, the vendor, the ware- 
house, and the accounts payable department. 
The unit with a purchasing need. 


timely, accurate, and cost-efficient provision of a particular purchasing item. In 
this case, the process delivers value both if the need for purchasing item is satis- 
fied by an timely, accurate, and cost-efficient shipment of a vendor, accompanied 
with an accurate payment procedure. 


. The shipment of goods can be accepted if accurate, leading to a corresponding 


payment, or they can be rejected if the amount or type of shipment is not correct. 


Solution 1.3 Possible measures include: 


1: 


4. 
5. 


Average time between the moment an application is received and the moment it 
is accepted or rejected (cycle time). Note that if the University advertises a pre- 
defined deadline for notifying acceptance/rejection, an alternative performance 
measure would be the percentage of times that this deadline is met. 

Percentage of applications rejected due to incomplete documents. Here we could 
distinguish between two variants of this measure: one that counts all cases where 
applications are initially rejected due to incomplete documents, and another one 
that counts the number of cases where applications are rejected due to incom- 
plete documents and where the applicant does not re-submit the completed ap- 
plication, for example because the deadline for applications has expired before 
the applicant gathers the required documents. 


. Percentage of applications rejected due to expired, invalid or low English lan- 


guage test results. 
Percentage of applications rejected due to advice from academic recognition. 
Percentage of accepted applications. 


Note that the cost incurred by the University per application is not a measure that 
is relevant from the perspective of the applicant, but it may be relevant from the 
perspective of the University. 


Solution 1.4 Possible issues include: 


1. 
2. 
3. 


Long execution times 

Inconvenience of gathering and submitting all required documents. 

Potentially: mishandled applications due to handovers of paper documents be- 
tween process participants. 
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Solution 1.5 


To reduce cycle time as well as mishandled applications, applications could be 
shared in electronic format between admissions office and academic committee. 
To reduce inconvenience of submission, applications could be evaluated in two 
stages. The first stage would involve purely electronically submitted documents 
(e.g. scanned copies instead of physical copies). Only applicants accepted by the 
academic committee would then need to go through the process of submitting 
certified copies of degrees by post for verification by the academic recognition 
agency. 


1.7 Further Exercises 


Exercise 1.6 Consider the following process at a pharmacy. 


Customers drop off their prescriptions either in the drive-through counter or in the front 
counter of the pharmacy. Customers can request that their prescription be filled immediately. 
In this case, they have to wait between 15 minutes and one hour depending on the current 
workload. Most customers are not willing to wait that long, so they opt to nominate a pick- 
up time at a later point during the day. Generally, customers drop their prescriptions in the 
morning before going to work (or at lunchtime) and they come back to pick up the drugs 
after work, typically between Spm and 6pm. When dropping their prescription, a technician 
asks the customer for the pick-up time and puts the prescription in a box labeled with the 
hour preceding the pick-up time. For example, if the customer asks to have the prescription 
be ready at 5pm, the technician will drop it in the box with the label 4pm (there is one box 
for each hour of the day). 

Every hour, one of the pharmacy technicians picks up the prescriptions due to be filled in the 
current hour. The technician then enters the details of each prescription (e.g. doctor details, 
patient details and medication details) into the pharmacy system. As soon as the details of 
a prescription are entered, the pharmacy system performs an automated check called Drug 
Utilization Review (DUR). This check is meant to determine if the prescription contains 
any drugs that may be incompatible with other drugs that had been dispensed to the same 
customer in the past, or drugs that may be inappropriate for the customer taking into account 
the customer data maintained in the system (e.g. age). 

Any alarms raised during the automated DUR are reviewed by a pharmacist who performs a 
more thorough check. In some cases, the pharmacist even has to call the doctor who issued 
the prescription in order to confirm it. 

After the DUR, the system performs an insurance check in order to determine whether 
the customer’s insurance policy will pay for part or for the whole cost of the drugs. In 
most cases, the output of this check is that the insurance company would pay for a certain 
percentage of the costs, while the customer has to pay for the remaining part (also called 
the co-payment). The rules for determining how much the insurance company will pay and 
how much the customer has to pay are very complicated. Every insurance company has 
different rules. In some cases, the insurance policy does not cover one or several drugs in a 
prescription, but the drug in question can be replaced by another drug that is covered by the 
insurance policy. When such cases are detected, the pharmacist generally calls the doctor 
and/or the patient to determine if it is possible to perform the drug replacement. 

Once the prescription passes the insurance check, it is assigned to a technician who collects 
the drugs from the shelves and puts them in a bag with the prescription stapled to it. Af- 
ter the technician has filled a given prescription, the bag is passed to the pharmacist who 
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double-checks that the prescription has been filled correctly. After this quality check, the 
pharmacist seals the bag and puts it in the pick-up area. When a customer arrives to pick up 
a prescription, a technician retrieves the prescription and asks the customer for payment in 
case the drugs in the prescription are not (fully) covered by the customer’s insurance. 


With respect to the above process, consider the following questions: 


. What type of process is the above one: order-to-cash, procure-to-pay or issue-to- 


resolution? 


. Who are the actors in this process? 

. What value does the process deliver to its customer(s)? 

. What are the possible outcomes of this process? 

. Taking the perspective of the customer, what performance measures can be at- 


tached to this process? 


. What potential issues do you foresee this process might have? What information 


would you need to collect in order to analyze these issues? 


. What possible changes do you think could be made to this process in order to 


address the above issues? 


Acknowledgement This exercise is partly inspired by Andrew McAfee: “Pharmacy 
Service Improvement at CVS (A)”. Harvard Business Publishing, 2005. 


Exercise 1.7 Consider the following process at a company of around 800 employ- 
ees. 


A purchase request is initiated when an employee at the company fills in and signs a form 
on paper. The purchase request includes information about the good to be purchased, the 
quantity, the desired delivery date, the approximate cost. The employee can also nominate 
a specific vendor. Employees often request quotes from vendors in order to get the required 
information. Completing the entire form can take a few days as the requestor often does 
not have the required data. The quote is attached to the purchase request. This completed 
request is signed by two supervisors. One supervisor has to provide a financial approval, 
while the other supervisor has to approve the necessity of the purchase and its conformance 
with company’s policy (e.g. does a requested software form part of the standard operating 
environment?). Collecting the signatures from the two supervisors takes on average five 
days. If it is urgent, the employee can hand-deliver the form, otherwise it is circulated via 
internal mail. A rejected purchase request is returned to the employee. Some employees 
make some minor modifications and try in a second attempt other supervisors in order to 
get approval. 

Once a purchase request is approved, it is returned to the employee who initiated the pur- 
chase requisition. The employee then forwards the form to the Purchasing Department. 
Many employees make a copy of the form for their own record, in case the form gets lost. 
The central purchasing Department checks the completeness of the purchase request and 
returns it to the employee if it is incomplete. 

Based on attached quotes and other information, the purchasing Department enters the ap- 
proved purchase request into the company’s Enterprise System. If the employee has not 
nominated any vendors, a clerk at the purchasing Department will select one based either 
on the quotes attached to the purchase requisition, or based on the list of vendors (also called 
Master Vendor List) available in the company’s Enterprise System. 

Sometimes the initial quote attached to the request has expired in the meantime. In this 
case, updated quote is requested from the corresponding vendor. In other cases, the vendor 
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who submitted the quote is not recorded in the company’s Enterprise System. In this case, 
the purchasing Department should give preference to other vendors who are registered in 
the Enterprise System. If no such vendors are available or if the registered vendors offer 
higher prices than the one in the submitted quote, the purchasing Department can add the 
new vendor into the Enterprise System. 

When a vendor is selected, a purchase order is automatically generated by the Enterprise 
System. Then, a fax is generated and sent to the vendor. A copy of the purchase order is 
sent to Accounts Payable Office, which is part of the Financial Department, which uses an 
accounting system that is not integrated with the Enterprise System. 

The goods are always delivered to the Goods Receipt Department. When a good is received, 
a clerk at this Department selects the corresponding purchase order in the Enterprise Sys- 
tem. The clerk checks the quantity and quality and (in the positive case) generates a docu- 
ment called goods receipt form from the purchase order stored in the Enterprise System. The 
goods are then forwarded to the employee who initiated the purchase requisition. A print- 
out of the goods receipt form is sent to the Accounts Payable Office. If there are any issues 
with the good, it is returned to the vendor and a paper-based note is sent to the Purchasing 
Department and to the Accounts Payable Office. 

The vendor eventually sends the invoice directly to the Accounts Payable Office. A clerk 
at this office compares the purchase order, the goods receipt and the invoice—a task that is 
usually called “three-way matching”. Three-way matching can be quite time-consuming. If 
there are any discrepancies as it has to be investigated, if it was an error of the vendor or 
a data entry error. The duration of the payment process unfortunately takes sometimes so 
long that the discount for paying in a certain period expires. 

A bank transfer is finally triggered and a payment notice is sent to the vendor. Some vendors 
explicitly indicate in their invoice the bank account number where they want the transfer 
to occur. It may happen that the bank account number and name indicated in the invoice 
differs from the one recorded in the vendor database. Sometimes payments bounce back, in 
which case the vendor is contacted by phone, e-mail or postal mail. If new bank details are 
given, the transfer is attempted again. If the issue is still not resolved, the Accounts Payable 
Office has to contact again the vendor in order to trace the cause of the bounced payment. 


. What type of process is the above one: order-to-cash, procure-to-pay or issue-to- 


resolution? 


. Who are the actors in this process? Who is/are the customer(s)? 

. What value does the process deliver to its customer(s)? 

. What are the possible outcomes of this process? 

. Taking the perspective of the customer, what performance measures can be at- 


tached to this process? 


. What potential issues do you foresee this process might have? What information 


would you need to collect in order to analyze these issues? 


. What possible changes do you think could be made to this process in order to 


address the above issues? 


Acknowledgement This exercise is adapted from a similar exercise developed by 


Michael Rosemann, Queensland University of Technology. 


Exercise 1.8 Consider the phases of the BPM lifecycle. Which of these phases are 
no included in a business process re-engineering project? 
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Geary Rummier is considered one of the earliest advocates of process thinking as an 
approach to address the shortcomings of purely functional organizations. His work 
on process thinking, developed during the 1970s and 1980s, was popularized by a 
book co-authored with Alan Brache: “Improving Performance: How to Manage the 
White Space on the Organizational Chart” [80]. A paper published two decades later 
by Rummler and Ramias [81] gives a condensed summary of Rummler’s methodol- 
ogy for structuring organizations around processes. 

Two key articles that popularized process thinking as a management concept are 
those of Hammer [26] and Davenport and Short [11] as discussed in this chapter. 
While Rummler’s work deals more broadly with structuring organizations based 
on processes, Hammer, Davenport and Short focus on how to redesign individual 
business processes to increase their performance. 

A comprehensive and consolidated treatment of BPM from a business man- 
agement perspective is provided by Paul Harmon in his book Business Pro- 
cess Change [31]. Harmon’s book presents the so-called BPTrends methodol- 
ogy for BPM. Harmon is also editor of the BPTrends newsletter and portal 
(http://www.bptrends.com) which features numerous articles and resources related 
to BPM. A good overview of the field is also provided in books by Becker et al. [6] 
and by Rosemann and vom Brocke [102, 103]. 

As mentioned in this chapter, BPM is related to several other fields, including 
TQM and Six Sigma. In this respect, Elzinga et al. [15] discuss the relation between 
BPM and TQM, while the application of Six Sigma techniques in the context of 
BPM is discussed by Harmon [31, Chap. 12], Laguna and Marklund [43, Chap. 2] 
and Conger [8]. 


Chapter 2 
Process Identification 


Things which matter most must never be at the mercy 
of things which matter least. 
Johann Wolfgang von Goethe (1749-1832) 


Process identification is a set of activities aiming to systematically define the set of 
business processes of a company and establish clear criteria for prioritizing them. 
The output of process identification is a process architecture, which represents the 
business processes and their interrelations. A process architecture serves as a frame- 
work for defining the priorities and the scope of process modeling and redesign 
projects. 

In this chapter, we present a method for process identification that is based on 
two phases: designation and evaluation. The designation phase is concerned with 
the definition of an initial list of processes. The evaluation phase considers suitable 
criteria for defining priorities of these processes. After that, we discuss and illustrate 
a method for turning the output of this method into a process architecture. 


2.1 Focusing on Key Processes 


Few organizations have the resources required to model all their processes in detail, 
to rigorously analyze and redesign each of them, to deploy automation technology 
in order to support each of these processes, and finally to continuously monitor 
the performance of all processes in detail. Even if such resources were available, 
it would not be cost-effective to spend them in this way. BPM is not free. Like any 
other investment, investments in BPM have to pay off. Thus, it is imperative in every 
organization engaged in BPM to focus the attention on a subset of processes. 

Some processes need to receive priority because they are of strategic importance 
to an organization’s survival. Other processes might show striking problems, which 
should be resolved for the sake of all involved stakeholders. In other words, the 
processes that an organization should focus on are found in areas where there is 
either great value created or significant trouble present (or both). To make things 
more complex, the subset of high-priority processes in an organization is subject to 
the dynamics of time. Some processes may be problematic at one point, but once 


M. Dumas et al., Fundamentals of Business Process Management, 33 
DOI 10.1007/978-3-642-33143-5_2, © Springer-Verlag Berlin Heidelberg 2013 


34 2 Process Identification 


the issues have been identified and resolved by a process improvement program, 
an organization can do with only periodic inspections for some time. For example, 
an insurance company suffering from high levels of customer dissatisfaction will 
naturally tend to focus on its customer-oriented processes, say its claims handling 
process. Once this process has improved and customer satisfaction is again within 
the desired range, the emphasis might move to its risk assessment processes, which 
are important for the long-term viability and competitiveness of the company. 

Beyond the dynamics of time, what may be processes that are of strategic im- 
portance to an organization at some point may grow less important as time elapses. 
Market demands may change and new regulations or the introduction of new prod- 
ucts may limit what was once a profitable business activity. For example, the arrival 
of new competitors offering discount insurance policies through Web-based chan- 
nels may push an established company to redesign its insurance sales processes to 
make them leaner, faster, and accessible from the Web. 

To address the imperative of focusing on a subset of key processes, the man- 
agement team, process analysts and process owners need to have answers to the 
following two questions: (i) what processes are executed in the organization? and 
(11) which ones should the organization focus on? In other words, an organization en- 
gaged in BPM initiatives needs to keep a map of its processes as well as clear criteria 
for determining which processes have higher priority. We have seen in Chap. | that 
there is a range of stakeholders involved in the management and execution of a busi- 
ness process. Generally, only a handful of such stakeholders have a full overview of 
all the business processes in an organization. Yet, it is precisely this insight that is 
required in order to identify the subset of processes that need to be closely managed 
or improved. Capturing this knowledge and keeping it up-to-date is precisely the 
aim of process identification. 

More specifically, process identification is concerned with two successive phases: 
designation and evaluation. The objective of the designation phase is to gain an un- 
derstanding of the processes an organization is involved in as well as their inter- 
relationships. The evaluation phase, based on the understanding that is established 
in the previous phase, intends to develop a prioritization among these for process 
management activities (modeling, redesign, automation, monitoring, etc.). Note that 
neither of these phases is concerned with the development of detailed process mod- 
els. The key activities that are involved with process identification which we will 
describe closely follow those as identified by Davenport in [10]. 


2.1.1 The Designation Phase 


If an organization is at the very start of turning into a process-centered organization, 
the first difficult task it faces is to come up with a meaningful enumeration of its 
existing processes. One difficulty here arises from the hierarchical nature of busi- 
ness processes: different criteria can be considered for determining which chains of 
operations can be seen as forming an independent business process and which ones 
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are seen as being part of another process. There are various views on how to catego- 
rize business processes (see the box “Categories of Processes according to Porter’). 
Some of these support the idea that there are actually very few processes within any 
organization. For example, some researchers have argued for the existence of only 
two processes: (1) managing the product line, and (2) managing the order cycle. 
Others identify three major processes: developing new products, delivering prod- 
ucts to customers, and managing customer relationships. 


CATEGORIES OF PROCESSES ACCORDING TO PORTER 

Different categorizations for business processes have been proposed. One 
of the most influential is Michael Porter’s Value Chain model. It distin- 
guishes two categories of processes: core processes (called primary activities) 
and support processes (support activities). Core processes cover the essen- 
tial value creation of a company, that is, the production of goods and ser- 
vices for which customers pay. Porter mentions inbound logistics, operations, 
outbound logistics, marketing and sales, and services. Support processes en- 
able the execution of these core processes. Porter lists infrastructure, human 
resources, technology development, and procurement as such support pro- 
cesses. As a third category, other authors extend this set of two categories 
with management processes. For example, the periodic process to assess the 
strength of competitors is such a management process. The distinction of core, 
support, and management processes is of strategic importance to a company. 
Therefore, if such a distinction is made explicit, e.g. at the stage of process 
identification or while creating a process architecture, it is likely to be a heav- 
ily disputed topic. 


The question is whether an overly coarse-grained view on processes, without 
any further subdivision, is useful for an organization that strives to become process- 
centered. Remember that the idea of process management is to actively manage 
business processes in the pursuit of satisfying its specific customers. If one selects 
business processes to be such large entities, then the result may be that these cannot 
be easily managed separately, both in terms of scope and speed of action. Consider, 
for example, how difficult it would be to model or redesign a process when it covers 
half of all the operations within an organization. A realistic model of such a busi- 
ness process would take a very long time to develop and could become extremely 
complex. Also, redesigning such a large process would be a time-consuming af- 
fair, let alone the implementation of such a redesign. Depending on the situation, an 
organization may not have that time. 

The main conclusion from this is that the number of processes that are identified 
in the designation phase must represent a trade-off between impact and manage- 
ability. The smaller the number of the processes one wishes to identify, the bigger 
their individual scope is. In other words, if only a small number of processes is 
identified then each of these will cover numerous operations. The main advantage 
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of a large process scope is that it potentially increases the impact one can have with 
actively managing such a process. The more operations are considered to be part of 
a process, the easier it will become, for example, to spot opportunities for efficiency 
gains by rooting out redundant work. 

On the other hand, a large scope of a business process brings along a range of 
issues that make it more difficult to manage it as a process: 


e the involvement of a large number of staff will make effective communication 
among them problematic 

e it will become more difficult to keep models of a large process up-to-date, and 

e improvement projects that are related to a large process are more complex 


To balance the advantages and disadvantages of a large process scope, Davenport 
has suggested that it may be useful to identify both broad and narrow processes. 
Broad processes are identified in those areas where an organization feels it is im- 
portant to completely overhaul the existing operations at some point, for example 
because of fierce competitive forces. Imagine that an organization may have found 
that its procurement costs are overly high compared to its competitors. They select 
procurement as a broad process, which covers all of the services and products the 
company acquires from other parties. By contrast, narrow processes are not targeted 
for major overhauls; they do need to be actively monitored and are subjected to con- 
tinuous fine-tuning and updating. A narrow process may be, for example, how the 
same company deals with improvement suggestions of its own employees. 


Exercise 2.1 Explain how the trade-off between impact and manageability works 
out for broad and narrow processes, respectively. 


Any enumeration of business processes should strive for a reasonably detailed 
outcome, which needs to be aligned with the organization’s specific goals of pro- 
cess management. For most organizations, as a rule of thumb, this will boil down 
to a dozen to a couple of dozens of business processes. Very large and diversified 
organizations might be better off with identifying a couple of hundred processes. 
To illustrate this: Within a multi-national investment firm, which employs close to 
3,000 staff and holds assets in the range of € 300 billion, 120 different business 
processes have been identified. To each of these business processes a process owner 
is assigned, who oversees the performance of the process and monitors the achieve- 
ment of its objectives in terms of customer satisfaction, profitability, and account- 
ability. Detailed process models are kept up-to-date, both as a means for document- 
ing planned changes to any process and for satisfying the requirements of financial 
authorities. By contrast, for a small medical clinic in the Netherlands, which em- 
ploys medical specialists, nurses, and administrative staff, 10 different treatment 
processes have been identified. A few of these have been mapped in the form of 
process models and are now in the process of being automated with a business pro- 
cess management system. For all other processes, it is sufficient to be aware of the 
distinctive treatment options they can provide to different patient categories. 
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Exercise 2.2 What are the potential drivers for the described investment firm to 
identify a large number of processes? 


In addition to a rather detailed view on what business processes exist, an under- 
standing must be developed about the relations between the various processes. In 
a situation where organizations define both narrow and broad processes, to avoid 
confusion, it is important to map how narrow processes relate to broader processes. 
A broad process like order management, for example, can be related to the more 
narrowly defined processes of order booking, billing, shipment, and delivery. All of 
these can be considered sub-processes of order management. We can call this an ex- 
ample of hierarchical relations between processes. Processes may also be related to 
one another differently. Billing, in the example we just used, is an upstream process 
compared to shipment: for the same order the bill is sent out usually before the or- 
dered goods are shipped. Another way of expressing this relation is, of course, that 
shipment can be considered a downstream process in comparison to billing. This 
illustrates how processes can be sequentially related. 


Exercise 2.3 Discuss in how far order management might be sequentially related 
to booking, billing, shipment, and delivery. 


Most of the time, the insight into the relations between processes may be less than 
strictly exact. The most important goal of capturing dependent relations is to gain 
an understanding of how the performance of a process is related to that of another. If 
one would, for example, redesign an existing process it is useful to understand which 
processes depend on the outcomes of such a process. Such downstream processes 
may need to be prepared for receiving information or goods in another frequency or 
form than before and measures should be taken to prevent any disruptions. 


Exercise 2.4 At this point, we discussed hierarchical and sequential relations be- 
tween business processes. Can you think of other types of relation that are useful to 
distinguish between processes? As a hint, you might want to think about the purpose 
of identifying the relations between business processes. 


While the designation of business processes and their inter-relationships is sub- 
ject to different design choices and preferences, some general guidance is available. 
First of all, several so-called reference models for business process identification 
exist. These are developed by a range of industry consortia, non-profit associations, 
government research programs and academia. The best-known examples are the In- 
formation Technology Infrastructure Library (ITIL), the Supply Chain Operations 
Reference Model (SCOR) by the Supply Chain Council, the Process Classification 
Framework (PCF) by the American Productivity and Quality Center (APQC), the 
Value Reference Model (VRM) by the Value Chain Group, and the Performance 
Framework of Rummler—Brache. Reference models standardize what can be seen as 
different processes, with unique characteristics and delivering distinguishable prod- 
ucts, and how their performance can be measured. Their largest value is in the iden- 
tification of regulatory or highly industry-specific processes, or when performance 
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benchmarking against peers and competitors is the issue that a process-centered 
organization is after. In other cases, these reference models may still be useful in 
identification exercises in the form of a checklist. For example, an organization can 
use the APQC’s PCF to inventory the processes in the framework they use, flag 
those they do not use, and add its own unique processes. We will take a closer look 
at the PCF in Sect. 2.2. 

A second stream of support is available in the form of specific design approaches 
to develop a so-called process architecture. A process architecture is an organized 
overview of the processes that exist within an organizational context, which is often 
accompanied with guidelines on how they should be organized. Design approaches 
for business process architectures use a certain logic to arrive at an identification of 
business processes. In Sect. 2.2, we will go into more detail with respect to a specific 
design approach. 

Finally, what is worth noting with respect to the designation phase is that pro- 
cesses change over time, deliberately or not. This naturally implies that process 
identification is of a continuous nature. To avoid the situation that one becomes 
bogged down in the stage of process identification, the activity should be consid- 
ered as an exploratory and iterative endeavor. When a certain stable overview is 
created it may very well be usable for a period of two to three years. 


2.1.2 The Evaluation Phase 


As stated before, not all processes are equally important and not all processes can 
receive the same amount of attention. Process management involves commitment, 
ownership, investment in performance enhancement, and optimization. Therefore, 
processes that create loss or risk demand for consolidation, decommissioning, or 
outright elimination. Various criteria have been proposed to steer this evaluation. 
The most commonly used ones are the following. 


Importance This criterion is concerned with assessing the strategic relevance of 
each process. The goal is to find out which processes have the greatest impact on 
the company’s strategic goals, for example considering profitability, continuity, 
or contribution to a public cause. It makes sense to select those processes for 
active process management that most directly relate to the strategic goals of an 
organization. 

Dysfunction This criterion aims to render a high-level judgment of the “health” 
of each process. The question here is to determine which processes are in the 
deepest trouble. These processes are the ones that may profit most from process- 
centered initiatives. 

Feasibility For each process, it should be determined how susceptible they are to 
process management initiatives, either incidental or on a continuous basis. Most 
notably, culture and politics involved in a particular process may be obstacles 
to achieve results from such initiatives. In general, process management should 
focus on those processes where it is reasonable to expect benefits. 
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Note that all of these criteria assume that there is certain information available. 
For example, to assess the strategic importance of a process it is of the utmost im- 
portance that an organization has an idea of its strategic course. It is sufficient if 
such strategic considerations are defined at a very abstract level. At this point, for 
example, many organizations see the strategic benefit of being able to change the 
kind of products it provides to the demands of customers. Zara, the Spanish cloth- 
ing retailer, is a prime example of an organization that follows a measure-and-react 
strategy. It sends out agents to shopping malls to see what people already wear for 
determining the styles, fabrics, and colors of the products it wants to deliver. Such an 
organization may look with specific interest at the production and logistic business 
processes that are best able to support this strategy. 

Similarly, to determine the potential dysfunction of a business process an orga- 
nization needs information. Here, we do encounter a “chicken and egg” problem. 
Many organizations that are not working in a process-centered way do not have a 
good, quantitative insight into the performance of their individual processes. One 
of the process-centered initiatives that such an organization may be after would 
exactly be to put the systems and procedures in place to collect the data that are 
needed for a performance assessment. In such cases, an organization will need to 
use more qualitative approaches to determine which of their processes do not per- 
form well, for example depending on the impressions that management or process 
participants have about the efficiency or effectiveness of the various processes. An- 
other approach would be to rely on customer evaluations, either gathered by surveys 
or spontaneously delivered in the form of complaints. 

The criterion of feasibility needs some attention too. It has become common 
practice for organizations to undergo a continuous stream of programs to improve 
their performance in one dimension or the other. Consider Philips, the multinational 
electronics company. It has gone through an intermittent range of improvement pro- 
grams since the 1980s to boost its performance. The same phenomenon can now 
be observed within many telecommunications and utility organizations. Since the 
profitability of products sharply changes from one year over the other, this requires 
continuous changes to product portfolios and market priorities. In these kinds of 
volatile context, it may happen that managers and process participants become tired 
of or outright hostile towards new initiatives. This kind of situation is not a good 
starting point for process management initiatives. After all, like other organizational 
measures, such initiatives also depend on the cooperation and good intentions of 
those directly involved. While we will not deal with the subject of change manage- 
ment in much detail in this textbook, it is important to realize that political sen- 
sitivities within an organization may have an effect on the success rate of process 
management efforts too. 


BPM MATURITY ASSESSMENT 
A more detailed approach to look at the evaluation phase is based on matu- 
rity. BPM maturity assessment is a body of techniques to determine the level 
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of systematic process thinking in an organization. A BPM maturity assess- 
ment essentially involves two aspects. The first aspect is to assess to what 
extent a given organization covers the range of processes that are ideally ex- 
pected from it. The second aspect is to assess to what degree these processes 
are documented and supported. Therefore, a maturity assessment is aimed at 
establishing a baseline for discussing the completeness and the quality of the 
set of processes executed in an organization. 

One of the most widely used frameworks for maturity assessment is the Ca- 
pability Maturity Model Integrated (CMMI) framework. This framework dis- 
tinguishes a number of so-called process areas. Several of these areas are spe- 
cific to a particular domain in the various CMMI specifications. The domain- 
independent areas include: process management, project management, and 
support. 

The coverage of process areas and the degree of their support provide the 
basis for a maturity assessment in terms of the five CMMI maturity levels: 


Level 1 (Initial): At this initial stage, the organization runs its processes in 
an ad-hoc fashion, without any clear definition of these processes. Control 
is missing. 

Level 2 (Managed): At this stage, project planning along with project mon- 
itoring and control have been put into practice. Measurement and analysis 
is established as well as process and product quality assurance. 

Level 3 (Defined): Organizations at this stage have adopted a focus on pro- 
cesses. Process definitions are available and organizational training is pro- 
vided to enable stakeholders across the organization to be engaged in pro- 
cess documentation and analysis. Integrated project and risk management 
are in place. Decision analysis and resolution are also in place. 

Level 4 (Quantitatively Managed): At this stage, organizational process 
performance is tracked. Project management is performed using quanti- 
tative techniques. 

Level 5 (Optimizing): At this stage of maturity, the organization has estab- 
lished organizational performance management accompanied with causal 
analysis and resolution. 


The assessment of an organization in terms of these levels leads to a so-called 
appraisal. Appraisals can be conducted internally within an organization (also 
called self-appraisals) or by an external organization with expertise in matu- 
rity assessment. Different types of appraisal are distinguished and defined in 
the Standard CMMI Appraisal Method for Process Improvement (SCAMPI). 


Question Given all the discussed criteria, does an assessment of the importance, 
dysfunctioning, and feasibility always point me to the same processes to actively 
manage? 
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No, there is no guarantee for that. It may very well be that a strategically impor- 
tant process is also the process that can be expected to be the most difficult one to 
manage, simply because so many earlier improvement efforts have already failed. 
An organization may not have a choice in such a situation. If a strategic process can- 
not be improved, this may turn out to be fatal for an organization as a whole. Think 
of a situation where the process to come up with new products creates much turmoil 
and conflicts within an organization: If the issues cannot be sorted out, the company 
may stop functioning quickly. In other settings, it may be more important to gain 
credibility with process management activities first. This can be accomplished by 
focusing on problematic processes of milder strategic importance but where there 
is a great desire to change. If successful, an improvement project at such a place 
may give credibility to the process management approach. These are not choices 
that can be easily prescribed without taking the specific context into situation. The 
various evaluation outcomes should be balanced to reach a list of those processes 
that should receive priority over others. 


Question Should all processes that are dysfunctional, of strategic importance, and 
feasible to manage be subjected to process management initiatives? 


The general answer to this question is that for most organizations this is not feasi- 
ble. Recall again that process management consumes resources. Even when there is 
a clear incentive to, for example, redesign various existing business processes, most 
organizations lack sufficient resources—people, funds, and time—to do so. Only the 
largest organizations are able to support more than a handful of process improve- 
ment projects at the same time. A good case in point is IBM, an organization known 
to have process improvement projects going on within all its existing business pro- 
cesses on a continuous basis. Another caveat of carrying out many simultaneous 
process management efforts is that these will create coordination complexity. Re- 
member that processes may be linked to each other in various respects, such that 
measures taken for one process should be synchronized with those taken for other. 
As Davenport [10] describes: 


Most companies choose to address a small set of business processes in order to gain expe- 
rience with innovation initiatives, and they focus their resources on the most critical pro- 
cesses. Each successful initiative becomes a model for future efforts. 


What is happening in some organizations is that widespread efforts are made 
to at least model all important business processes, delaying the decision to make 
the step to more advanced BPM efforts (e.g. process redesign or automation). The 
idea is that process models are a cornerstone of any further BPM efforts in any 
case and that their existence will help to better understand where improvements 
can be gained. Creating a model of a process leads to the valuable insight how that 
process works at all, and can provide a good basis for small improvements that can 
easily be implemented. On the downside, such an approach bears the risk that major 
improvements are missed and stakeholders develop a feeling of a lack of return 
for the efforts. It should be stressed here, too, that the actual modeling of business 
processes is not an element of the process identification stage. 
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Fig. 2.1 The different levels 
of detail in a process 
architecture 
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In this section, we have described the process designation and evaluation phases 
on a high level of discourse. Now, we will turn to a specific technique to come up 
with a process design architecture. 


2.2 Designing a Process Architecture 


A process architecture is a conceptual model that shows the processes of a company 
and makes their relationships explicit. Typically, these relationships are defined in 
two directions. On the one hand, processes can be in a consumer-—producer relation- 
ship. This means that one process provides an output that the other process takes as 
an input. In the first part of the book, we distinguished the quote-to-order process 
and order-to-cash processes. The output of the first one (the order) is the input to the 
second one. Note that this is the same kind of ordering as the upstream-downstream 
relation we distinguished earlier. Beyond the consumer—producer relation, a pro- 
cess architecture defines different levels of detail. This is illustrated as a pyramid in 
Fig. 2.1. 

The part of the process architecture that covers the processes on level one is 
known as the process landscape model or simply the process architecture for level 
one. It shows the main processes on a very abstract level. Each of the elements of 
the process landscape model points to a more concrete business processes on level 
two. This level two shows the processes at a finer degree of granularity, but still in a 
quite abstract way. Each element on level two points further to a process model on 
level three. The process models on this third level show the detail of the processes 
including control flow, data inputs and outputs, and assignment of participants, as 
we will discuss in the modeling chapters. 

The most important challenge for the definition of a process architecture is the 
definition of the process landscape model, i.e. capturing the processes on level one. 
The process architecture on level one has to be understandable in the first place, 
showing not much more than approximately 20 categories of business processes of 
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a company. Furthermore, it has to be sufficiently complete such that all employees 
of the company can relate to it with their daily work, and accept it as a consensual 
description of the company. Therefore, it is important to define the process archi- 
tecture in a systematic way, with a specific focus on the derivation of the process 
landscape model. 

Several perspectives and approaches have been defined for process architecture 
definition. Here, we will concentrate on an approach developed by Dijkman [14]. 
This specific approach leads to a process architecture on level one along two di- 
mensions: case type and business function. The case type dimension classifies the 
types of cases that are handled by an organization. A case is something that an or- 
ganization (or part of it) handles. Typically, a case is a product or service that is 
delivered by an organization to its customers, such as an insurance (a service) or a 
toy (a product). Note that, depending on the part of the organization for which the 
process architecture is designed, the cases can represent products or services that 
are delivered to the customers of the organization. However, they can also refer to 
products or services that are delivered by one department of the organization to an- 
other department. For example, think of setting up a workplace for a new employee 
by the facilities department. 

Cases can be deliberately classified, using any number of properties. For exam- 
ple, an insurance company handles insurances, which can be classified according to 
product type (home insurance, car insurance and life insurance), but also according 
to the channel that the company uses to interact with its customers (telephone, of- 
fice, and internet). A combination of these properties can also be used to classify 
cases. In the insurance example, cases would then be classified using both product 
type and channel (home-insurance via telephone, home-insurance via office, car- 
insurance via telephone, etc.). 

The function dimension classifies the functions of an organization. A function is, 
simply put, something that an organization does. Typically, a hierarchical decom- 
position of functions can be made: A function consists of sub-functions, which, in 
turn, consist of sub-sub-functions, etc. For example, a production company performs 
purchasing, production, and sales functions. The purchasing function, in turn, can 
be decomposed into vendor selection and operational procurement functions. Fig- 
ure 2.2 shows an example of a business process architecture for a harbor authority, 
which uses the case type and function dimensions to structure its processes. 

The figure shows an organization of processes by case type in the horizontal di- 
mension and by business function in the vertical dimension. The function dimension 
shows what the organization does: handling pre-arrival of sea ships, which involves 
notifying the relevant parties about the estimated time of arrival of the ship and what 
the ship is carrying; handling the actual arrival of the ship, which involves guiding 
the ship to its dock; etc. The case type dimension shows the types of cases that the 
organization handles: sea ships, trucks, trains, and inland transportation by barge. 
There are three processes that are created to handle these types of cases, using the 
different functions. These three are shown as covering the various functions and case 
types. The inbound planning process is used for handling pre-arrival of sea ships. 
The inbound handling process is used for handling arrival and trans-shipment of sea 
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Fig. 2.2. A process architecture for a harbor authority 


ships and the outbound handling process is used for handling trans-shipment and 
departure of trucks, trains, and barges. 

To arrive at a business process architecture in a similar sense as we described 
here, we propose an approach that consists of the following four steps: 


. identify case types 

. identify functions for case types 

. construct one or more case/function matrices, and 
. identify processes 


BRWNe 


We will now discuss these steps in more detail. 


2.2.1 Identify Case Types 


In the first step, a classification of case types is developed for the organization. This 
is done by selecting the case properties that will be used for the classification. The 
main purpose for identifying different classes in this dimension of the process archi- 
tecture is to determine the different ways in which (similar) processes are handled 
in the organization. It is important to have this in mind, because the only properties 
that should be included in the classification are the ones that lead to different organi- 
zational behavior. Properties that may distinguish cases yet do not lead to different 
behavior should not be included. For example, a stationary store sells many differ- 
ent types of product. However, it sells all these types of product in the same manner. 
Therefore, ‘product type’ is not a useful dimension when classifying the cases that 
are handled by a retail store. An insurance company also sells different types of 
product (insurances) and, in contrast to the retail store, the products that it sells are 
handled differently. For example, for a life insurance a declaration of health must be 
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filled out, but for a car insurance this is not a requirement. Therefore, the “product 
type’ is indeed a useful property to classify the types of cases that are handled by 
an insurance company; this is not the so for classifying the types of cases that are 
handled by a retail store. 

A classification of the types of cases that an organization handles can be devel- 
oped using any number of properties. However, some of the more commonly used 
properties are: 


e Product type: this property identifies the types of products that are handled by 
an organization. These can be hierarchically decomposed. For example, an insur- 
ance company handles damages and life insurance products. In the class of dam- 
age insurances, a further decomposition is possible into car insurance and home 
insurance; similarly, within the class of life insurance a further decomposition is 
possible into healthcare insurance and accident insurance. 

e Service type: if (a part of) an organization handles services rather than products, 
this property identifies the types of services that the organization handles, similar 
to the way in which product type identifies the types of tangible deliverables. 

e Channel: this property represents the channel through which the organization con- 
tacts its customers. We can, for example, distinguish: face-to-face contact (over 
the counter), telephone or internet contact. 

e Customer type: this property represents the types of customer that the organi- 
zation deals with. An airline, for example, may distinguish frequent flyers from 
regular travelers. 


Note again that, although these are the most commonly used properties to dis- 
tinguish different case types, there are certainly other properties that can be used. 
Any property that distinguishes types of cases that are handled differently can be 
used. For example, if an organization does things differently in North America than 
in Europe, cases may be classified according to location. Another example: if cases 
are handled differently depending on the expertise that is required to handle them, 
they may be classified according to expertise. 

Also, note again that the classification can be developed using any number and 
combination of properties. If a company sells insurances in both North America 
and Europe and handling of insurances differs on those continents because of local 
regulations, then a classification of cases according to both product type and location 
can be used. 


Exercise 2.5 Consider the case of a bank and the classification criteria product type, 


service type, channel, and customer type. In how far are these criteria related to each 
other? 


2.2.2 Identify Functions for Case Types 


In the second step, a classification is developed of the business functions that are 
performed on the different case types. This step requires that each of the case types 
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is examined in detail and for each case type the functions that can be performed on it 
are identified. Potentially, the functions that are performed in an organization can be 
related to existing classifications that are proposed by reference models. We already 
mentioned a number of these. A small part of APQC’s PCF is shown in Table 2.1. 
Such reference models can serve as a starting point to develop a classification of 
business functions and may be adapted to the specific needs of the organization. 

Whether this identification of functions starts with a reference model or not, it 
requires interviews with different people in the organization. These interviews serve 
to either identify the functions directly, or to check to which extent the functions 
from a reference model apply to the organization. The interviews must both be held 
with employees that are involved in the different cases that the organization han- 
dles and with product (and service) managers of the different products and services 
that the organization handles. It is, therefore, important to observe that the different 
people involved may very well use different terms for similar business functions. 
Homonyms and synonyms are problematic in this context. For example, what is 
called ‘acquisition’ in one part of the organization may be called ‘market survey’ in 
another (synonym). At the same time, two functions called ‘implementation’ may 
represent different activities: one may represent the implementation of software, 
while the other represents the implementation of new regulations in the organiza- 
tion (homonym). Apart from being aware of the various terms that are being used, 
an intricate understanding of the operations of an organization is important to sort 
these issues out. Frameworks like APQC’s PCF can help to avoid terminological 
issues right from the start. 

In addition, functions may be organized differently. Consider, for example, 
Fig. 2.3. It is taken from a real-world case and shows parts of the functional de- 
compositions of two departments from the same organization, one in Europe and 
one in North America. The European department distinguishes between purchasing 
and sales, where both purchasing and sales are split up into operational functions. 
These functions concern sourcing and order-to-pay for purchasing on the one hand 
and marketing and sales operations for sales on the other. The North American de- 
partment distinguishes between sourcing, marketing, and order handling. Here, or- 
der handling involves both order-to-pay and operational sales activities (but is not 
decomposed any further). 

Clearly, in the example of this organization, a negotiation step may be required 
between the different people involved to unify the functional decompositions across 
its European and North-American parts. This is particularly called for if the func- 
tional decomposition is more than just a modeling exercise. It may also represent 
actual organizational properties. In the case that is illustrated in Fig. 2.3, managers 
are in place for the different functions at the different levels of decomposition. In 
Europe, a manager is appointed for sales, another for procurement, and lower-level 
managers for sourcing, order-to-pay, marketing, and operational sales. In North 
America, there are managers in place for sourcing, marketing, and order manage- 
ment. Therefore, when the functional decompositions of the departments needs to 
be harmonized, the management structure also must be subjected to harmonization. 

A functional decomposition should not be confused with a decomposition ac- 
cording to case type. It is possible that an organization is structured according to 
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Table 2.1 Level one and level two of the APQC process classification framework 


1.0 Develop Vision and Strategy 

1.1 Define the business concept and long-term 
vision 

1.2 Develop business strategy 

1.3 Manage strategic initiatives 


2.0 Develop and Manage Products and Services 


2.1 Manage product and service portfolio 
2.2 Develop products and services 


3.0 Market and Sell Products and Services 

3.1 Understand markets, customers, and 
capabilities 

3.2 Develop marketing strategy 

3.3 Develop sales strategy 

3.4 Develop and manage marketing plans 

3.5 Develop and manage sales plans 


4.0 Deliver Products and Services 

4.1 Plan for and align supply chain resources 
4.2 Procure materials and services 

4.3 Produce/Manufacture/Deliver product 
4.4 Deliver service to customer 

4.5 Manage logistics and warehousing 


5.0 Manage Customer Service 

5.1 Develop customer care/customer service 
strategy 

5.2 Plan and manage customer service 
operations 

5.3 Measure and evaluate customer service 
operations 


6.0 Develop and Manage Human Capital 

6.1 Develop and manage human resources 
(HR) planning, policies, and strategies 

6.2 Recruit, source, and select employees 

6.3 Develop and counsel employees 

6.4 Reward and retain employees 

6.5 Redeploy and retire employees 

6.6 Manage employee information 


7.0 Manage Information Technology 

7.1 Manage the business of information 
technology 

7.2 Develop and manage IT customer 
relationships 

7.3 Develop and implement security, privacy, 
and data protection controls 

7.4 Manage enterprise information 

7.5 Develop and maintain information 
technology solutions 


7.6 Deploy information technology solutions 
7.7 Deliver and support information 
technology services 


8.0 Manage Financial Resources 

8.1 Perform planning and management 
accounting 

8.2 Perform revenue accounting 

8.3 Perform general accounting and reporting 

8.4 Manage fixed-asset project accounting 

8.5 Process payroll 

8.6 Process accounts payable and expense 
reimbursements 

8.7 Manage treasury operations 

8.8 Manage internal controls 

8.9 Manage taxes 

8.10 Manage international funds/consolidation 


9.0 Acquire, Construct, and Manage Assets 

9.1 Design and construct/acquire 
nonproductive assets 

9.2 Plan maintenance work 

9.3 Obtain and install assets, equipment, and 
tools 


9.4 Dispose of productive and nonproductive 
assets 


10.0 Manage Enterprise Risk, Compliance, 
and Resiliency 

10.1 Manage enterprise risk 

10.2 Manage business resiliency 

10.3 Manage environmental health and safety 


11.0 Manage External Relationships 

11.1 Build investor relationships 

11.2 Manage government and industry 
relationships 

11.3 Manage relations with board of directors 
11.4 Manage legal and ethical issues 

11.5 Manage public relations program 


12.0 Develop and Manage Business 

Capabilities 

12.1 Manage business processes 

12.2 Manage portfolio, program, and project 

12.3 Manage quality 

12.4 Manage change 

12.5 Develop and manage enterprise-wide 
knowledge management (KM) 
capability 

12.6 Measure and benchmark 


48 2 Process Identification 


Europe North America 
c = 

S sourcing & | sourcing 

S purchasing 2 

S order-to-pay Se 

s w | marketing 

3 marketing 8 

‘= | sales x7) 

n 8 i 

3B ? 5 | order handlin 
2 operational sales 2 9 


Fig. 2.3. Different functional decompositions within the same organization 


both business function and other properties. It may then be tempting to develop 
the functional decomposition further according to these other properties. However, 
these other properties should be reflected in the case type dimension rather than the 
function dimension. For example, an organization can be structured according to 
business functions into a sales and a procurement department with managers leading 
each of the departments. It can be further structured according to location, having 
both a sales and a procurement department in Europe as well as in North America. In 
this situation, the functional decomposition ends with the decomposition into sales 
and procurement. Should a further decomposition according to location be relevant, 
then this decomposition should be reflected in the case type dimension, not in the 
function dimension. 

An important decision that must be made when developing the functional de- 
composition is to determine the appropriate level of decomposition at which the 
functional decomposition ends. In theory, the functional decomposition can be per- 
formed up to a level that represents the tasks that are performed by the individual 
employee (fill-out form, check correctness of information on form, have colleague 
check correctness of information on form, etc.). However, for a process architecture 
a more coarse level of decomposition is usually chosen. Two rules of thumb that can 
be used to choose the level of decomposition at which the functional decomposition 
ends, are the following. 


1. The functional decomposition should at least be performed down to a level at 
which functions correspond to different organizational units (with corresponding 
managers). For example, if an organization has both a sourcing and an order-to- 
pay department and both have their own managers, this is a strong indication that 
the functional decomposition should contain the functions that are performed by 
these departments. 

2. The functional decomposition should include different functions for the different 
roles in each department. For example, if the sourcing department has buyers, 
who do requirements analysis and vendor selection, as well as senior buyers, who 
do vendor relationship management and contract management, this may lead to a 
decision to include requirements analysis, vendor selection, vendor relationship 
management and contract management as functions. 
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Observe that these are rules of thumb, which leave room for handling them flex- 
ibly. They merely provide an aid for determining the lowest level of decomposition 
that should be used. 


Exercise 2.6 Consider the case of a university and the level one processes listed 
in the APQC’s PCF. What kind of more specific functions does a university typi- 
cally cover in categories 2.0 Develop and Manage Products and Services and in 5.0 
Manage Customer Service? 


2.2.3 Construct Case/Function Matrices 


The previous two steps of the described approach lead to a matrix that has the dif- 
ferent case types as columns and the different functions as rows. A cell in the matrix 
contains an ‘X’, if the corresponding function can be performed for the correspond- 
ing case type. Figure 2.4 shows an example of a case/function matrix. The matrix 
shows a decomposition of case types by customer type, resulting in three case types: 
one for private customers, one for corporate customers, and one for internal cus- 
tomers. The figure also shows a functional decomposition into three main functions 
and a subsequent decomposition of those main functions into ten sub-functions. 
Management and support functions are only performed for internal customers, while 
operational functions are performed for private and corporate customers. 

A case/function matrix can be split up into multiple matrices for the purpose of 
improving readability. We would typically split up a case/function matrix in case 
a partition of the matrix’ functions and case types is possible such that all X’s are 
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Fig. 2.5 A case/function matrix evolving into a process landscape model (applying Guideline 1) 


preserved. For example, the matrix from Fig. 2.4 can be partitioned into, on the one 
hand, a matrix that contains the management and support functions and the internal 
customers and, on the other, a matrix that contains the operational functions and the 
private and corporate customers. 


2.2.4 Identify Processes 


In the fourth and final step of the proposed approach, we determine which combi- 
nations of business functions and case types form a business process. To determine 
this, we need to find a trade-off between two extremes, one in which the entire ma- 
trix forms one big process and one in which each single cross in the matrix forms a 
process. We establish this trade-off by the use of the general rule that, in principle, 
the entire matrix forms one big process which will only be split up in case certain 
rules apply. These rules can be formulated as eight guidelines. When a guideline 
applies, this may lead to a separation of processes between rows (a vertical split) 
or to a separation of processes between columns (a horizontal split). Some of the 
guidelines (Guidelines 5, 6, and 8) can only lead to vertical splits, while others 
(Guidelines 1-4) can only lead to horizontal splits. Note that the guidelines are not 
absolute: they may or may not apply to a particular organization and they are not 
the only rules that should be considered in specific cases. 

Figure 2.5 shows the running example that we will use to explain the guidelines. 
The figure shows a case/function matrix for a mortgage broker, which brokers mort- 
gages both in the Netherlands and in Belgium. It distinguishes between simplex 
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and composite mortgages. A composite mortgage can be adapted to the specific re- 
quirements of a customer, by composing it from different types of loans, savings 
accounts, life insurances and investment accounts. A simplex mortgage consists of 
a pre-defined package of a loan, a savings account and a life insurance. On these dif- 
ferent types of mortgages, various business functions can be performed. Risk assess- 
ment involves assessment of risk of both individual clients, who are in the process 
of applying for a mortgage, and mortgage products as a whole. Mortgage brokerage 
involves the selection of a particular mortgage package based on the requirements 
of a particular customer and subsequently offering that package to the customer and 
closing the contract. The financial functions involve paying out the mortgage and 
subsequently collecting the monthly payments. Finally, product development is the 
periodic review of the mortgage products and their components. 


Guideline 1: If a process has different flow objects, it can be split up vertically. 
A flow object is an object in the organization that flows through a business pro- 
cess. It is the object on which business process activities are being carried out. 
Typically, each business process has a single flow object, such that flow objects 
can be used to identify business processes. Consequently, if multiple flow objects 
can be identified in a business process, this is a strong indication that the process 
should be split up. 


Figure 2.5 illustrates the application of Guideline | to our running example. One 
flow object for the mortgage brokering process is a mortgage application on which 
activities are carried out during a mortgage application by a client. These activities 
include a risk assessment and paying out the mortgage to the client. Another flow 
object in the mortgage brokering process is a mortgage product on which activities 
are carried out periodically to assess the risk of the product as a whole and to evalu- 
ate and develop the product. Consequently, we can split up the mortgage brokering 
process into two processes, one that has a mortgage application as a flow object and 
one that has a mortgage product as a flow object. We call the former the mortgage 
application process and the latter the product development and assessment process. 


Guideline 2: If the flow object of a process changes multiplicity, the process can be 
split up vertically. This is due to the fact that in a business process a single flow 
object is sometimes used, while at other times multiple flow objects of the same 
type are used. This is typical for batch processing, in which certain activities are 
performed for multiple customer cases in batch at the same time. If, in the same 
process, the number of flow objects that is processed per activity differs this may 
be a reason for splitting up the process. 


Have a look at Fig. 2.5, where the mortgage application process is performed for 
a single mortgage application. By contrast, the collection of payments happens for 
all mortgages in batch by the end of each month. Using Guideline 2, this may be 
taken as the reason for splitting the process and having Mortgage Collection as a 
separate process. 


Guideline 3: If a process changes transactional state, it can be split up vertically. 
According to the action-workflow theory, a business process goes through a num- 
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ber of transactional states. In particular, we distinguish: the initiation, the ne- 
gotiation, the execution and the acceptance state. In the initiation state, contact 
between a customer and a provider is initiated. In the negotiation state, the cus- 
tomer and the provider negotiate about the terms of service or delivery of a prod- 
uct. During the execution state, the provider delivers the product or service to the 
customer and during the acceptance state, the customer and the provider negoti- 
ate about the acceptance and payment of the delivery. A transition in a process 
from one state to another is an indication that the process can be split up. 


To illustrate this guideline, consider again Fig. 2.5. Suppose that during the ne- 
gotiation state the mortgage broker and the customer negotiate about the selection 
of mortgage products, ultimately leading to a contract being signed by both par- 
ties. Only during the execution state the mortgage is paid out to the customer and 
the monthly payments will be collected. By the logic of Guideline 3, we therefore 
split up the process into a mortgage application process and a Mortgage Payment 
process. 


Guideline 4: Ifa process contains a logical separation in time, it can be split up ver- 
tically. A process contains a logical separation in time, if its parts are performed 
at different time intervals. Intervals that can typically be distinguished include: 
once per customer request, once per day, once per month and once per year. 


To clarify Guideline 4, consider Fig. 2.5 again. Mortgage selection, offering, and 
contracting are performed once per mortgage application, while payment and col- 
lection for mortgages is performed once per month. By the logic of Guideline 4, 
it would make sense to split up mortgage selection, offering, and contracting from 
mortgage payment collection. Note that the passing of time in itself is not a reason 
for splitting up a process, because within each single process, time passes. For ex- 
ample, between the activity of entering mortgage details into a computer system and 
approval of the mortgage, time passes, but the unit of time remains the same: both 
activities happen once per mortgage application. Therefore, we would not split up 
the process between these activities. Another way of looking at Guideline 4 is that 
the process can be split up, if it must wait for a time trigger or a trigger by a new 
flow object. For example, the approval of a mortgage can be performed directly after 
the mortgage details are entered, without having to wait for a trigger. However, after 
having processed the mortgage application, the process must wait for the payment 
collection date trigger to continue with payment collection. Therefore, we would 
split up the process between these functions by the same logic of Guideline 4. 


Guideline 5: If a process contains a logical separation in space, it can be split up 
horizontally. A process contains a logical separation in space, if it is performed at 
multiple locations and is performed differently at those locations. It is important 
to note that it is not sufficient for processes to just be separated in space. The 
separation must be such that there is no choice but to perform the processes 
differently for the different logical units. 


To clarify this guideline: in case a process is performed at different locations 
within the same country, there is not necessarily a reason to perform it differently 
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at those locations. Consequently, there is no reason to split it up. In fact, organiza- 
tions should strive to make their processes as uniform as possible, to benefit from 
economies of scale. Indeed many organizations nowadays started projects in which 
they aim to make their processes more uniform across different locations, where 
processes became different purely for historic reasons or because the different lo- 
cations did not share information about their process flow. As another example, the 
processes from Fig. 2.5 are performed at two different locations in different coun- 
tries. However, still not all of these processes should differ at these two locations. 
For example, mortgage payment and collection may be the same in Belgium and 
the Netherlands. However, risk assessment, mortgage brokering and product devel- 
opment may differ between the Netherlands and Belgium, due to country-specific 
rules and regulations. 
Guidelines 6 and 7 are more straightforward and can be described as follows. 


Guideline 6: If a process contains a logical separation in another relevant dimen- 
sion, it can be split up horizontally. Like with the separation in space, it is not 
sufficient for processes to just be separated. The separation must be such that 
there is no choice but to perform the processes differently for the different logi- 
cal units. 

Guideline 7: If a process is split up in a reference model, it can be split up. A refer- 
ence process architecture is an existing process architecture that is pre-defined as 
a best-practice solution. It structures a collection of processes. For example, if a 
reference financial services process architecture exists, its structure can be used 
as an example or starting point to structure your own process architecture. 


Figure 2.6 shows the results of applying Guidelines 2 through to 7 to the 
case/function matrix from Fig. 2.5, which itself resulted from applying Guideline 1 
to our running example. Figure 2.6 shows that after applying Guidelines 2 through 
7 as discussed above, there are six processes: Product Development and Assess- 
ment Netherlands (PD NL), Product Development and Assessment Belgium (PD 
BE), Mortgage Application Netherlands, Mortgage Application Belgium, Mortgage 
Payment, and Mortgage Collection. 

The final guideline that we discuss here is the following. 


Guideline 8: If a process covers (many) more functions in one case type than in 
another, it can be split up horizontally. The application of this last rule depends 
upon the current decomposition of processes. If applied, it is necessary to look 
at the current decomposition of processes and check if, within a process, (many) 
more functions are performed for one case type than for another, i.e.: whether 
a process has many more crosses in one column than in another. If so, this is a 
strong indication that the process should be split up for these two case types. 


For example, when looking at Fig. 2.6, we see that the Mortgage Application 
Netherlands process has many more function for composite mortgages than for sim- 
plex mortgages. By the logic of Guideline 8, we would split up this process for 
composite and simplex application. The application of all of these eight guidelines 
yields a process architecture for level one. The result can be seen in Fig. 2.7, which 
is the finalized process landscape model for our example. 
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Fig. 2.7 A case/function matrix evolving into a process landscape model (applying Guideline 8) 


2.2 Designing a Process Architecture 55 


Table 2.2 

Consumer-producer Consumer Producer 

relationships between 

processes Mortgage Payment Composite Mortgage Application NL 
Mortgage Payment Simplex Mortgage Application NL 
Mortgage Payment Mortgage Application BE 


2.2.5 Complete the Process Architecture 


The approach that we discussed previously and which we emphasize in this part of 
the book leads to a process landscape model that covers the processes on level one 
of the pyramid in Fig. 2.1. As stated, this level only provides a very abstract insight 
into each process within the process landscape: It mainly shows how processes differ 
from each other in terms of the cases and functions they cover. 

There are two things that are missing with respect to the general, encompass- 
ing characteristics of a process architecture as we discussed in Sect. 2.2: (1) the 
consumer—producer relationships between the processes, and (2) the levels of detail 
as provided by the pyramid in Fig. 2.1. 

With respect to the consumer—producer relationships, we can take a broad or nar- 
row perspective on the use of an output from one process as the input of another. 
For our running example, it may be that the product development process uses ag- 
gregated figures about how the mortgage application process is carried to determine 
what the needs of clients are and, in this way, what attractive new products may be. 
This would be a rather broad interpretation of the consumer—producer relationship. 

What is often most important to know stems from a narrower perspective, namely 
which consumer—producer relationships exist between processes with respect to the 
same flow objects. In Fig. 2.7, it can be seen that mortgage application (both in 
the Netherlands and Belgium) and mortgage payment are split up, which was done 
following the logic of Guideline 3. This is a situation where the flow object of one 
process is consumed piecemeal by another; the only difference is the transactional 
state that the flow object is in. Specifically with respect to redesign initiatives these 
relations are most important to remember and make explicit, since changing one 
process has direct implications for the performance of the other. We can capture this 
narrow interpretation of consumer—producer relationships for our running example 
as is done in Table 2.2. Each row in this table provides a single consumer—producer 
relationship, where the consumer process continues to work on a flow object that is 
the output of the producer process. 

Let us now focus on the other aspect that makes a process architecture for level 
one rather restrictive in comparison to our general notion of a process architecture. 
This concerns the high level of abstraction of the processes that are distinguished by 
the process landscape model. To focus on the other levels of the pyramid of Fig. 2.1, 
the question is what kind of additional detail they should offer. We focus here on 
the missing insights into (a) the various steps that are taken within each process 
and (b) the organizational units that are involved in carrying these out. These two 
elements should be added to obtain the models for level two of what we mean by 
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Fig. 2.8 A process map for the mortgage payment process 


a process architecture. It is common to refer to a model on this second level as a 
process map. 

To provide an example of a process map, we focus on the mortgage payment 
process that is identified in the process landscape model of Fig. 2.7. The related 
process map can be seen in Fig. 2.8. 

As this figure shows, the identified mortgage payment process from the process 
landscape model has been decomposed into four main steps that can be associated 
with this process. Moreover, two organizational units are identified that are asso- 
ciated with these steps, i.e. Accounting and Billing. In other words, a process map 
provides more detail about the control flow and includes additional information with 
respect to the involved resources for a process. 

Even a process map can still be said to provide an abstract view on a process. 
First of all, we can still see that the flow throughout the steps in a process map 
is highly simplified. It is common, like in Fig. 2.8, to only show a linear progress 
along the various steps in a process map: alternative paths, potential exceptions, 
iterations, etc. are all left out. For the organizational information that is added in a 
process map, too, the information is abstract: we can only see references to units but 
not the specific kind of participants that are involved. 


Exercise 2.7 Give an example of an alternative path, a potential exception, and an 
iteration that would show up in a more detailed model of the mortgage payment 
process. 


Secondly, there are many aspects beyond control flow and resource information 
that are not covered in any level of detail in a process map. Think about the data that 
are being handled in the process, the reports and files that are passed on, the systems 
that support the various steps, the time that is involved with carrying out these steps, 
etc. 

In practice, process maps have turned out to provide a deeper level of insight into 
the processes from the process landscape regardless of the goals one pursues for the 
specific processes. In other words, an insight into the steps and involved organiza- 
tional units has its value for any type of process-oriented initiative. By contrast, a 
further insight into, for example, the data that are being processed within each step 


2.3 Recap 57 


would only make sense if someone pursues to automate the process or when the 
evaluation phase has identified quality issues. 

In this textbook, we will not focus on the development of process maps. Instead, 
we will turn to the more detailed level of models, i.e. those on level three of a process 
architecture. As will be shown, these models are developed following specific rules 
and provide the insight that are ideally closely tied to what one likes to achieve with 
a specific process management initiative. This will be the subject of the following 
chapters. 


2.3 Recap 


In this chapter, we have discussed process identification. First, we distinguished 
and described the phases of designation and evaluation. The designation phase aims 
at enumerating the major processes within an organization, as well as determining 
the boundaries between those processes. An insight into the major processes that 
are being carried out in an organization is important to set up any process man- 
agement activity. The evaluation phase is dedicated to prioritizing process analysis 
and redesign efforts. It is good practice to base priorities upon the importance of 
processes, their potential dysfunction, and the feasibility of improvements. 

The designation phase may be used not only to enumerate the most important 
processes, but also to design a consistent overarching process architecture. A pro- 
cess architecture defines the relationship between the different processes. Often, 
different levels of detail are distinguished. We discussed a specific approach for the 
definition of level one of the process architecture. This approach builds on the iden- 
tification of case types, of the functions for these case types, the construction of a 
case/function matrix, the identification of processes based on guidelines, and the 
eventual completion of the architecture. 


2.4 Solutions to Exercises 


Solution 2.1 Explain how the trade-off between impact and manageability works 
out for broad and narrow processes, respectively. A broad process has by definition 
a large scope. Managing it actively potentially can have a large impact on an organi- 
zation’s performance. The flip side is that it is more difficult to actively manage such 
a broad process or the improvement projects that are related to it. For a narrow pro- 
cess, this is exactly the other way around: given its smaller scope, it is more easily 
managed but it will probably have a lesser impact on an organization’s performance 
as a whole. 


Solution 2.2 The description of the investment firm points at large financial hold- 
ings, which may be related to the employment of many different products (invest- 
ment instruments) for many different customers, both private and institutional. Both 
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of these dimensions, products and customers, may drive the firm to identify different 
processes that cater for these. In addition, the description of the firm also mentions 
‘accountability’: for many financial organizations, there are strict requirements on 
how they must manage and disclose their operation, as imposed on them by regu- 
latory agencies. This, too, may be a driver for the identification of many different 
processes. 


Solution 2.3 Order management is not sequentially related to any of these. As dis- 
cussed in the text, booking, billing, shipment, and delivery are all sub-processes of 
order management. So, it is impossible to indicate that any of these sub-processes 
precedes or follows up on order management; rather, they are subsumed by this 
process. 


Solution 2.4 Organizations wish to accomplish certain goals. Processes are a means 
to achieve these goals. A relation that, therefore, may be important is how processes 
are related to one another in the sense that they contribute to the same or related 
goals. Other, context-specific relations may be important for organizations as well. 
Consider how it may be important for an organization to know on which technolo- 
gies their processes are based; if a particular technology becomes obsolete, such an 
organization knows which processes are affected. A similar line of reasoning can be 
taken for geographic areas, regulations, etc. 


Solution 2.5 Many banks distinguish different types of customers, and use this dis- 
tinction for defining product and service types for them as much as channels. For 
instance, a retail bank customer is typically characterized by a low to average in- 
come who requires transaction services and products for building up wealth. Often, 
banks try to serve these customers via standardized channels like telephone and in- 
ternet in order to limit transaction costs. On the contrary, private bank customers are 
typically have high income or possess a considerable fortune. Banks invest much 
more into personal advise and consulting of these customers and in offering indi- 
vidual packages of products and services. Often, such strategic considerations as 
of those a bank in this example have the consequence that different classification 
criteria are often correlated. 


Solution 2.6 The products and services of a university relate to teaching and certifi- 
cation, and essentially support the lifecycle of a student towards obtaining a degree. 
Therefore, the category 2.0 mainly relates to the development and management of 
curricula and degree programs. The academic entities of a university are concerned 
with these tasks. The category 5.0 would refer to the management of student ser- 
vices. Usually, tasks belonging to this category are organized in an examinations 
office of the university assisting in all study-related matters. 


Solution 2.7 An example of alternative paths in the mortgage payment process 
would be that different payment conditions lead to payment collection activities. 
An example of an exception in this process would be that the account balance is 
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not sufficient to collect a payment. An example of an iteration would be that after a 
failed payment collection this is tried again (perhaps after a certain delay). 


2.5 Further Exercises 


Exercise 2.8 A university provides education and services to its students. This starts 
with admission of students to the university. When a regular student, i.e. a student 
who comes from a Dutch high-school, sends in his admission form such a student is 
registered by the admissions office. Subsequently, the eligibility to study in a certain 
program is checked based on the information that the student provided on his ad- 
mission form. For students who arrive from another school, such as a polytechnic, 
the previous study that the student took, according to his admission form, must be 
examined in detail. Polytechnic students can either come to the university after com- 
pleting one year of courses (propedeuse) or after receiving a polytechnic diploma. 
Students from universities in other countries are also accepted. Also for them, the 
studies that they took previously must be examined in detail. When students are 
considered eligible and the courses that they have already followed (if applicable) 
check out, they are enrolled at the university, which involves sending a letter that 
they are accepted and entering the details of their enrollment in the information sys- 
tem of the university. The students then become a student of their respective study: 
industrial engineering, building or construction engineering. 

After the students are enrolled, they can take courses or do projects and they can 
use the services that are provided by the university, which include: language training 
and sports facilities. Projects are done on an individual basis by a student together 
with a lecturer. The university recognizes part-time students who do their studies 
while they are working in a company. These students typically do projects of a more 
practical nature than the other students, such that the process that is followed during 
the project are also different for these students. 

Design a process architecture as follows: 


. identify the case types that should appear in the process architecture 

. identify the functions that should appear in the process architecture 

. draw a case/function matrix 

. identify the processes in the case function matrix, split up processes if and only if 
one of the guidelines applies, clearly indicate which guideline you applied where 


BRWN Re 


Exercise 2.9 A consultancy firm provides consultancy, outsourcing, and interim 
management services. The firm considers acquisition of projects as part of those 
services. Acquisition can both be done for existing clients and for new clients, be- 
cause it concerns acquisition of projects rather than clients. Acquisition is typically 
started at ‘networking events’ by partners of the consultancy firm. It is handled 
according to a fixed procedure, but no standard document is used. When a client 
shows interest in a consultancy service, an intake is done with the client. To main- 
tain a long-term relationship with clients as much as possible, the firm will always 
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try to establish a framework contract with new clients during the intake. For exist- 
ing clients a framework contract does not have to be established. As another form 
of relationship management, regular meetings are held with existing clients. During 
these meetings the client’s organization is discussed with the client. This enables 
the client to decide whether additional work should be done to further improve the 
organization. At the same time this enables the firm to bring in additional assign- 
ments. The intake and the regular meetings happen according to the same form, on 
which an inventory of the client’s wishes can be made. 

For consultancy and outsourcing services, a project team must be created directly 
after a project assignment was given to the consultancy firm. After a project team is 
created, there is a kick-off meeting with the client and after the kick-off meeting, the 
project is executed. The kick-off meeting is the same for each type of project, but 
the way in which the project is executed differs largely per type of service. At the 
end of the project there always is an evaluation meeting with the client as a means of 
quality control. The creation of the project team, the kick-off meeting, the execution 
of the project and the evaluation of the project happen according to a project plan. 

The consultancy company has a services department, which takes care of market 
research for the consultants, manages the leasing of cars and provides secretary 
services. 

Design a process architecture as follows: 


. identify the case types that should appear in the process architecture 

. identify the functions that should appear in the process architecture 

. draw a case/function matrix 

. identify the processes in the case function matrix; split processes if and only if 
one of the guidelines applies and indicate which guideline you applied where 


BRWNrR 


2.6 Further Reading 


The importance of explicit identification of processes was perhaps first discussed by 
Davenport [10], while a similar perspective is offered by Hammer & Champy [29]. 
Sharp & McDermott [86] give practical advice on exploring the process land- 
scape—an alternative term for process architecture. Another practical book cov- 
ering process architecture design is that of Ould [64]. One of the questions left open 
by these books is to what extent it pays off to identify and delineate processes in a 
company-specific manner as opposed to adopting standardized reference models for 
this purpose. 

Dijkman [14] provides a survey of popular process architecture approaches. One 
of the findings of this survey is that practitioners tend to apply a mix of styles to de- 
rive process architectures and that no single, popular approach is followed. Despite 
the practical interest in the topic, there is a little academic research into the area of 
process architectures. Exceptions are the work by Frolov et al. [20] and Zur Muehlen 
et al. [112]. Both groups of authors emphasize the importance of a hierarchical pro- 
cess architectures. It remains unclear though to what extent prescribed, normative 
approaches provided by academia are applicable and beneficial in practice. 
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The concept of value chain—which generally appears at the top of a process 
architecture—was popularized by Michael Porter [67]. Porter also contributed to 
popularizing the distinction between core process (which he called primary activ- 
ity) and support process. A detailed reference model centered around the notion of 
value chain is the Value Reference Model (VRM) defined by the Value Chain Group 
(http://www.value-chain.org/). 

Related and to some extent complementary to the concept of value chain is the 
organizational performance framework of Rummler & Brache [80]. In this frame- 
work, organizations are viewed as systems whose purpose is to produce value within 
a certain environment, which includes competitors, suppliers, capital markets, labor 
markets, regulations, and other external factors. Within this environment, organi- 
zations create value by procuring materials or resources from suppliers in order to 
manufacture or deliver products or services for customers. The created value leads 
to earnings for shareholders. 

Rummler & Ramias [81] describe a variant of Rummler & Brache’s framework, 
namely the Value Creation Hierarchy (VCH). In this framework, the system that 
transforms resources into products or services is called the Value Creation System 
(VCS). The VCS is decomposed into processing sub-systems, which in turn are 
decomposed into end-to-end processes and then into sub-processes, tasks, and sub- 
tasks. The VCH thus provides a conceptual framework that goes all the way from 
the organizational context to the lowest level of a process architecture. 


Chapter 3 
Essential Process Modeling 


Essentially, all models are wrong, but some are useful. 
George E.P. Box (1919-) 


Business process models are important at various stages of the BPM lifecycle. Be- 
fore starting to model a process, it is crucial to understand why we are modeling 
it. The models we produce will look quite differently depending on the reason for 
modeling them in the first place. There are many reasons for modeling a process. 
The first one is simply to understand the process and to share our understanding 
of the process with the people who are involved with the process on a daily basis. 
Indeed, process participants typically perform quite specialized activities in a pro- 
cess such that they are hardly confronted with the complexity of the whole process. 
Therefore, process modeling helps to better understand the process and to identify 
and prevent issues. This step towards a thorough understanding is the prerequisite 
to conduct process analysis, redesign or automation. 

In this chapter we will become familiar with the basic ingredients of process 
modeling using the BPMN language. With these concepts, we will be able to pro- 
duce business process models that capture simple temporal and logical relations 
between activities, data objects and resources. First, we will describe some essential 
concepts of process models, namely how process models relate to process instances. 
Then, we will explain the four main structural blocks of branching and merging in 
process models. These define exclusive decisions, parallel execution, inclusive de- 
cisions and repetition. Finally, we will cover information artifacts and resources 
involved in a process. 


3.1 First Steps with BPMN 


With over 100 symbols, BPMN is a fairly complex language. But as a learner, there 
is no reason to panic. A handful of those symbols will already allow you to cover 
many of your modeling needs. Once you have mastered this subset of BPMN, the 
remaining symbols will naturally come to you with practice. So instead of describ- 
ing each and every BPMN symbol at length, we will learn BPMN by introducing its 
symbols and concepts gradually, by means of examples. 
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Fig. 3.1 The diagram of a simple order fulfillment process 


In this chapter we will become familiar with the core set of symbols provided by 
BPMN. As stated earlier, a business process involves events and activities. Events 
represent things that happen instantaneously (e.g. an invoice has been received) 
whereas activities represent units of work that have a duration (e.g. an activity to 
pay an invoice). Also, we recall that in a process, events and activities are logically 
related. The most elementary form of relation is that of sequence, which implies that 
one event or activity A is followed by another event or activity B. Accordingly, the 
three most basic concepts of BPMN are event, activity, and arc. Events are repre- 
sented by circles, activities by rounded rectangles, and arcs (called sequence flows 
in BPMN) are represented by arrows with a full arrow-head. 


Example 3.1 Figure 3.1 shows a simple sequence of activities modeling an order 
fulfillment process in BPMN. This process starts whenever a purchase order has 
been received from a customer. The first activity that is carried out is confirming the 
order. Next, the shipment address is received so that the product can be shipped to 
the customer. Afterwards, the invoice is emitted and once the payment is received 
the order is archived, thus completing the process. 


From the example above we notice that the two events are depicted with two 
slightly different symbols. We use circles with a thin border to capture start events 
and circles with a thick border to capture end events. Start and end events have an 
important role in a process model: the start event indicates when instances of the 
process start whereas the end event indicates when instances complete. For exam- 
ple, a new instance of the order fulfillment process is triggered whenever a purchase 
order is received, and completes when the order is fulfilled. Let us imagine that 
the order fulfillment process is carried out at a seller’s organization. Every day this 
organization will run a number of instances of this process, each instance being 
independent of the others. Once a process instance has been spawned, we use the 
notion of token to identify the progress (or state) of that instance. Tokens are cre- 
ated in a start event, flow throughout the process model until they are destroyed in 
an end event. We depict tokens as colored dots on top of a process model. For ex- 
ample Fig. 3.2 shows the state of three instances of the order fulfillment process: 
one instance has just started (black token on the start event), another is shipping the 
product (red token on activity “Ship product’), and the third one has received the 
payment and is about to start archiving the order (green token in the sequence flow 
between “Receive payment” and “Archive order’). 

While it comes natural to give a name (also called Jabel) to each activity, we 
should not forget to give labels to events as well. For example, giving a name to 
each start event allows us to communicate what triggers an instance of the process, 
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Fig. 3.2. Progress of three instances of the order fulfillment process 


meaning, when should a new instance of the process be started. Similarly, giving 
a label to each end event allows us to communicate what conditions hold when an 
instance of the process completes, i.e. what the outcome of the process is. 

We recommend the following naming conventions. For activities, the label should 
begin with a verb in the imperative form followed by a noun, typically referring to 
a business object, e.g. “Approve order”. The noun may be preceded by an adjective, 
e.g. “Issue driver license”, and the verb may be followed by a complement to ex- 
plain how the action is being done, e.g. “Renew driver license via offline agencies”. 
However, we will try to avoid long labels as this may hamper the readability of the 
model. As arule of thumb, we will avoid labels with more than five words excluding 
prepositions and conjunctions. Articles are typically avoided to shorten labels. For 
events, the label should begin with a noun (again, this would typically be a business 
object) and end with a verb in past participle form, e.g. “Invoice emitted”. The verb 
is a past participle to indicate something that has just happened. Similar to activ- 
ity labels, the noun may be prefixed by an adjective, e.g. “Urgent order sent”. We 
capitalize the first word of activity and event labels. 

General verbs like “to make”, “to do”, “to perform” or “to conduct” should be 
replaced with meaningful verbs that capture the specifics of the activity being per- 
formed or the event occurring. Words like “process” or “order” are also ambiguous 
in terms of their part of speech. Both can be used as a verb (“to process’, “to or- 
der’) and as a noun (“a process”, “‘an order’). We recommend to use such words 
consistently, only in one part of speech, e.g. “order” always as a noun. 

To name a process model we should use a noun, potentially preceded by an ad- 
jective, e.g. “order fulfillment” or “claim handling” process. This label can be ob- 
tained by nominalizing the verb describing the main action of a business process, 
e.g. “fulfill order” (the main action) becomes “order fulfillment” (the process label). 
Nouns in hyphenated form like “order-to-cash” and “procure-to-pay” indicating the 
sequence of main actions in the process, are also possible. 

We do not capitalize the first word of process names, e.g. the “order fulfillment” 
process. By following such naming conventions we will keep our models more con- 
sistent, make them easier to understand for communication purposes and increase 
their reusability. 

The example in Fig. 3.1 represents one possible way of modeling the order ful- 
fillment process. However, we could have produced a quite different process model. 
For example, we could have neglected certain activities or expanded on certain oth- 
ers, depending on the specific intent of our modeling. The box “A bit on modeling 
theory” reflects on the properties that underpin a model and relates these to the spe- 
cific case of process models. 
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A BIT ON MODELING THEORY 

A model is characterized by three properties: mapping, abstraction, and fit 
for purpose. First, a model implies a mapping of a real-world phenomenon— 
the modeling subject. For example, a residential building to be constructed 
could be modeled via a timber miniature. Second, a model only documents 
relevant aspects of the subject, i.e. it abstracts from certain details that are ir- 
relevant. The timber model of the building clearly abstracts from the materials 
the building will be constructed from. Third, a model serves a particular pur- 
pose, which determines the aspects of reality to omit when creating a model. 
Without a specific purpose, we would have no indication on what to omit. 
Consider the timber model again. It serves the purpose of illustrating how the 
building will look like. Thus, it neglects aspects that are irrelevant for judging 
the appearance, like the electrical system of the building. So we can say that a 
model is a means to abstract from a given subject with the intent of capturing 
specific aspects of the subject. 


Fig. 3.3 A building (a), its timber miniature (b) and its blueprint (c). ((b): © 2010, Bree 
Industries; (c): used by permission of planetclaire.org) 


A way to determine the purpose of a model is to understand the target au- 
dience of the model. In the case of the timber model, the target audience could 
be a prospective buyer of the building. Thus, it is important to focus on the ap- 
pearance of the building, rather than on the technicalities of the construction. 
On the other hand, the timber model would be of little use to an engineer who 
has to design the electrical system. In this case, a blueprint of the building 
would be more appropriate. 

Thus, when modeling a business process, we need to keep in mind the 
specific purpose and target audience for which we are creating the model. 
There are two main purposes for process modeling: organizational design 
and application system design. Process models for organizational design are 
business-oriented . They are built by process analysts and mainly used for 
understanding and communication, but also for benchmarking and improve- 
ment. As such, they need to be intuitive enough to be comprehended by the 
various stakeholders, and will typically abstract from IT-related aspects. The 
target audience includes managers, process owners and business analysts. Pro- 
cess models for application system design are [T-oriented . They are built by 
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system engineers and developers, and used for automation. Thus, they must 
contain implementation details in order to be deployed to a BPMS, or used as 
blueprints for software development. 

In this and in the next chapter we will focus on the business-oriented pro- 
cess models. In Chap. 9 we will learn how to turn these process models exe- 
cutable. 


3.2 Branching and Merging 


Activities and events may not necessarily be performed sequentially. For example, 
in the context of a claim handling process, the approval and the rejection of a claim 
are two activities which exclude each other. So these activities cannot be performed 
in sequence, since an instance of this process will perform either of these activities. 
When two or more activities are alternative to each other, we say they are mutually 
exclusive. 

Let us consider another situation. In the claim handling process, once the claim 
has been approved, the claimant is notified and the disbursement is made. Notifi- 
cation and disbursement are two activities which are typically performed by two 
different business units, hence they are independent of each other and as such they 
do not need to be performed in sequence: they can be performed in parallel, i.e. at 
the same time. When two or more activities are not interdependent, they are concur- 
rent. 

To model these behaviors we need to introduce the notion of gateway. The term 
gateway implies that there is a gating mechanism that either allows or disallows 
passage of tokens through the gateway. As tokens arrive at a gateway, they can be 
merged together on input, or split apart on output depending on the gateway type. 
We depict gateways as diamonds and distinguish them between splits and joins. 
A split gateway represents a point where the process flow diverges while a join 
gateway represents a point where the process flow converges. Splits have one incom- 
ing sequence flow and multiple outgoing sequence flows (representing the branches 
that diverge), while joins have multiple incoming sequence flows (representing the 
branches to be merged) and one outgoing sequence flow. 

Let us now see how examples like the above ones can be modeled with gateways. 


3.2.1 Exclusive Decisions 


To model the relation between two or more alternative activities, like in the case 
of the approval or rejection of a claim, we use an exclusive (XOR) split. We use an 
XOR-join to merge two or more alternative branches that may have previously been 
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Fig. 3.4 An example of the use of XOR gateways 


forked with an XOR-split. An XOR gateway is indicated with an empty diamond 
or with a diamond marked with an “X’’. From now on, we will always use the “X” 
marker. 


Example 3.2 Invoice checking process. 


As soon as an invoice is received from a customer, it needs to be checked for mismatches. 
The check may result in either of these three options: i) there are no mismatches, in which 
case the invoice is posted; ii) there are mismatches but these can be corrected, in which 
case the invoice is re-sent to the customer; and iii) there are mismatches but these cannot 
be corrected, in which case the invoice is blocked. Once one of these three activities is 
performed the invoice is parked and the process completes. 


To model this process we start with a decision activity, namely “Check invoice 
for mismatches” following a start event “Invoice received”. A decision activity is 
an activity that leads to different outcomes. In our example, this activity results 
in three possible outcomes, which are mutually exclusive; so we need to use an 
XOR-split after this activity to fork the flow into three branches. Accordingly, three 
sequence flows will emanate from this gateway, one towards activity “Post invoice”, 
performed if there are no mismatches, another one towards “Re-send invoice to 
customer’, performed if mismatches exist but can be corrected, and a third flow 
towards “Block invoice’, performed if mismatches exist which cannot be corrected 
(see Fig. 3.4). From a token perspective, an XOR-split routes the token coming from 
its incoming branch towards one of its outgoing branches, i.e. only one outgoing 
branch can be taken. 

When using an XOR-split, make sure each outgoing sequence flow is annotated 
with a label capturing the condition upon which that specific branch is taken. More- 
over, always use mutually exclusive conditions, i.e. only one of them can be true 
every time the XOR-split is reached by a token. This is the characteristic of the 
XOR-split gateway. In our example an invoice can either be correct, or contain mis- 
matches that can be fixed, or mismatches that cannot be fixed: only one of these 
conditions is true per invoice received. 
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In Fig. 3.4 the flow labeled “mismatches exist but cannot be corrected” is marked 
with an oblique cut. This notation is optional and is used to indicate the default 
flow, i.e. the flow that will be taken by the token coming from the XOR-split in 
case the conditions attached to all the other outgoing flows evaluate to false. Since 
this arc has the meaning of otherwise, it can be left unlabeled. However, we highly 
recommend to still label this arc with a condition for readability purposes. 

Once either of the three alternative activities has been executed, we merge the 
flow back in order to execute activity “Park invoice” which is common to all three 
cases. For this we use an XOR-join. This particular gateway acts as a passthrough, 
meaning that it waits for a token to arrive from one of its input arcs and as soon as 
it receives the token, it sends the token to the output arc. In other words, with an 
XOR-join we proceed whenever an incoming branch has completed. 

Coming back to our example, we complete the process model with an end event 
“Invoice handled”. Make sure to always complete a process model with an end 
event, even if it is obvious how the process would complete. 


Exercise 3.1 Model the following fragment of a business process for assessing loan 
applications. 


Once a loan application has been approved by the loan provider, an acceptance pack is 
prepared and sent to the customer. The acceptance pack includes a repayment schedule 
which the customer needs to agree upon by sending the signed documents back to the loan 
provider. The latter then verifies the repayment agreement: if the applicant disagreed with 
the repayment schedule, the loan provider cancels the application; if the applicant agreed, 
the loan provider approves the application. In either case, the process completes with the 
loan provider notifying the applicant of the application status. 


3.2.2 Parallel Execution 


When two or more activities do not have any order dependencies on each other 
(i.e. one activity does not need to follow the other, nor it excludes the other) they 
can be executed concurrently, or in parallel. The parallel (AND) gateway is used to 
model this particular relation. Specifically, we use an AND-split to model the parallel 
execution of two or more branches, and an AND-join to synchronize the execution 
of two or more parallel branches. An AND gateway is depicted as a diamond with a 
“4? mark. 


Example 3.3 Security check at the airport. 


Once the boarding pass has been received, passengers proceed to the security check. Here 
they need to pass the personal security screening and the luggage screening. Afterwards, 
they can proceed to the departure level. 


This process consists of four activities. It starts with activity “Proceed to security 
check” and finishes with activity “Proceed to departure level”. These two activities 
have a clear order dependency: a passenger can only go to the departure level after 
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Fig. 3.5 An example of the use of AND gateways 


undergoing the required security checks. After the first activity, and before the last 
one, we need to perform two activities which can be executed in any order, i.e. which 
do not depend on each other: “Pass personal security screening” and “Pass luggage 
screening”. To model this situation we use an AND-split linking activity “Proceed 
to security check” with the two screening activities, and an AND-join linking the 
two screening activities with activity “Proceed to departure level” (see Fig. 3.5). 

The AND-split splits the token coming from activity “Proceed to security check” 
into two tokens. Each of these tokens independently flows through one of the two 
branches. This means that when we reach an AND-split, we take all outgoing 
branches (note that an AND-split may have multiple outgoing arcs). As we said 
before, a token is used to indicate the state of a given instance. When multiple to- 
kens of the same color are distributed across a process model, e.g. as a result of 
executing an AND-split, they collectively represent the state of an instance. For ex- 
ample, if a token is on the arc emitting from activity “Pass luggage screening” and 
another token of the same color is on the arc incident to activity “Pass personal 
security screening’, this indicates an instance of the security check process where 
a passenger has just passed the luggage screening but not yet started the personal 
security screening. 

The AND-join of our example waits for a token to arrive from each of the two 
incoming arcs, and once they are all available, it merges the tokens back into one. 
The single token is then sent to activity “Proceed to departure level”. This means that 
we proceed when all incoming branches have completed (note again that an AND- 
join may have multiple incoming arcs). This behavior of waiting for a number of 
tokens to arrive and then merging the tokens into one is called synchronization. 


Example 3.4 Let us extend the order fulfillment example of Fig. 3.1 by assuming 
that a purchase order is only confirmed if the product is in stock, otherwise the pro- 
cess completes by rejecting the order. Further, if the order is confirmed, the shipment 
address is received and the requested product is shipped while the invoice is emit- 
ted and the payment is received. Afterwards, the order is archived and the process 
completes. 

The resulting model is shown in Fig. 3.6. Let us make a couple of remarks. First, 
this model has two activities that are mutually exclusive: “Confirm order” and “Re- 
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ject order”, thus we preceded them with an XOR-split (remember to put an activity 
before an XOR-split to allow the decision to be taken, such as a check like in this 
case, or an approval). Second, the two sequences “Get shipment address’—“Ship 
product” and “Emit invoice’—“Receive payment” can be performed independently 
of each other, so we put them in a block between an AND-split and an AND-join. In 
fact, these two sets of activities are typically handled by different resources within 
a seller’s organization, like a sales clerk for the shipment and a financial officer for 
the invoice, and thus can be executed in parallel (note the word “meantime” in the 
process description, which indicates that two or more activities can be performed at 
the same time). 


Let us compare this new version of the order fulfillment process with that in 
Fig. 3.1 in terms of events. The new version features two end events while the first 
version features one end event. In a BPMN model we can have multiple end events, 
each capturing a different outcome of the process (e.g. balance paid vs. arrears pro- 
cessed, order approved vs. order rejected). BPMN adopts the so-called implicit ter- 
mination semantics, meaning that a process instance completes only when each to- 
ken flowing in the model reaches an end event. Similarly, we can have multiple start 
events ina BPMN model, each event capturing a different trigger to start a process 
instance. For example, we may start our order fulfillment process either when a new 
purchase order is received or when a revised order is resubmitted. If a revised order 
is resubmitted, we first retrieve the order details from the orders database, and then 
continue with the rest of the process. This variant of the order fulfillment model is 
shown in Fig. 3.7. An instance of this process model is triggered by the first event 
that occurs (note the use of an XOR-join to merge the branches coming from the 
two start events). 


Exercise 3.2. Model the following fragment of a business process for assessing loan 
applications. 
A loan application is approved if it passes two checks: (i) the applicant’s loan risk assess- 


ment, done automatically by a system, and (ii) the appraisal of the property for which the 
loan has been asked, carried out by a property appraiser. The risk assessment requires a 


72 3 Essential Process Modeling 


Reject order 


roduct 


not in stock Order 


rejected 


Check stock 
availability 


New purchase order 
received 


product 
in stock 


Retrieve 
order details 


Revised 
purchase order 
received 


Fig. 3.7 A variant of the order fulfillment process with two different triggers 


credit history check on the applicant, which is performed by a financial officer. Once both 
the loan risk assessment and the property appraisal have been performed, a loan officer can 
assess the applicant’s eligibility. If the applicant is not eligible, the application is rejected, 
otherwise the acceptance pack is prepared and sent to the applicant. 


There are two situations when a gateway can be omitted. An XOR-join can be 
omitted before an activity or event. In this case, the incoming arcs to the XOR-join 
are directly connected to the activity/event. An example of this shorthand notation 
is shown in Fig. 1.6, where there are two incident arcs to activity “Select suitable 
equipment”. An AND-split can also be omitted when it follows an activity or event. 
In this case, the outgoing arcs of the AND-split emanate directly from the activ- 
ity/event. 


3.2.3 Inclusive Decisions 


Sometimes we may need to take one or more branches after a decision activity. 
Consider the following business process. 


Example 3.5 Order distribution process. 


A company has two warehouses that store different products: Amsterdam and Hamburg. 
When an order is received, it is distributed across these warehouses: if some of the relevant 
products are maintained in Amsterdam, a sub-order is sent there; likewise, if some relevant 
products are maintained in Hamburg, a sub-order is sent there. Afterwards, the order is 
registered and the process completes. 


Can we model the above scenario using a combination of AND and XOR gate- 
ways? The answer is yes. However, there are some problems. Figures 3.8 and 3.9 
show two possible solutions. In the first one, we use an XOR-split with three alter- 
native branches: one taken if the order only contains Amsterdam products (where 
the sub-order is forwarded to the Amsterdam warehouse), another taken if the order 
only contains Hamburg products (similarly, in this branch the sub-order is forwarded 
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Fig. 3.8 Modeling an inclusive decision: first trial 
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Fig. 3.9 Modeling an inclusive decision: second trial 


to the Hamburg warehouse), and a third branch to be taken in case the order con- 
tains products from both warehouses (in which case sub-orders are forwarded to 
both warehouses). These three branches converge in an XOR-join which leads to 
the registration of the order. 

While this model captures our scenario correctly, the resulting diagram is some- 
what convoluted, since we need to duplicate the two activities that forward sub- 
orders to the respective warehouses twice. And if we had more than two warehouses, 
the number of duplicated activities would increase. For example, if we had three 
warehouses, we would need an XOR-split with seven outgoing branches, and each 


activity would need to be duplicated four times. Clearly this solution is not scal- 
able. 
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Fig. 3.10 Modeling an inclusive decision with the OR gateway 


In the second solution we use an AND-split with two outgoing arcs, each 
of which leads to an XOR-split with two alternative branches. One is taken 
if the order contains Amsterdam (Hamburg) products, in which case an ac- 
tivity is performed to forward the sub-order to the respective warehouse; the 
other branch is taken if the order does not contain any Amsterdam (Hamburg) 
products, in which case nothing is done until the XOR-join, which merges 
the two branches back. Then an AND-join merges the two parallel branches 
coming out of the AND-split and the process completes by registering the or- 
der. 

What is the problem with this second solution? The example scenario allows 
three cases: the products are in Amsterdam only, in Hamburg only, or in both ware- 
houses, while this solution allows one more case, i.e. when the products are in 
neither of the warehouses. This case occurs when the two empty branches of the 
two XOR-splits are taken and results in doing nothing between activity “Check or- 
der line items” and activity “Register order’. Thus this solution, despite being more 
compact than the first one, is wrong. 

To model situations where a decision may lead to one or more options be- 
ing taken at the same time, we need to use an inclusive (OR) split gateway. An 
OR-split is similar to the XOR-split, but the conditions on its outgoing branches 
do not need to be mutually exclusive, i.e. more than one of them can be true 
at the same time. When we encounter an OR-split, we thus take one or more 
branches depending on which conditions are true. In terms of token seman- 
tics, this means that the OR-split takes the input token and generates a num- 
ber of tokens equivalent to the number of output conditions that are true, where 
this number can be at least one and at most as the total number of outgoing 
branches. Similar to the XOR-split gateway, an OR-split can also be equipped 
with a default flow, which is taken only when all other conditions evaluate to 
false. 

Figure 3.10 shows the solution to our example using the OR gateway. After the 
sub-order has been forwarded to either of the two warehouses or to both, we use 
an OR-join to synchronize the flow and continue with the registration of the order. 
An OR-join proceeds when all active incoming branches have completed. Waiting 
for an active branch means waiting for an incoming branch that will ultimately de- 
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Fig. 3.11 What type should the join gateway have such that instances of this process can complete 
correctly? 


liver a token to the OR-join. If the branch is active, the OR-join will wait for that 
token, otherwise it will not. Once all tokens of active branches have arrived, the 
OR-join synchronizes these tokens into one (similarly to what an AND-join does) 
and sends that token to its output arc. We call this behavior synchronizing merge 
as opposed to the simple merge of the XOR-join and the synchronization of the 
AND-join. 


Let us delve into the concept of active branch. Consider the model in Fig. 3.11, 
which features a join gateway with undefined type (the one grayed out with a ques- 
tion mark). What type should we assign to this join? Let us try an AND-join to 
match the preceding AND-split. We recall that an AND-join waits for a token to ar- 
rive from each incoming branch. While the token from the branch with activity “C” 
will always arrive, the token from the branch with activities “B” and “D” may not 
arrive if this is routed to “E” by the XOR-split. So if activity “D” is not executed, 
the AND-join will wait indefinitely for that token, with the consequence that the 
process instance will not be able to progress any further. This behavioral anomaly 
is called deadlock and should be avoided. 

Let us try an XOR-join. We recall that the XOR-join works as a passthrough 
by forwarding to its output branch each token that arrives through one of its input 
branches. In our example this means that we may execute activity “F’ once or twice, 
depending whether the preceding XOR-split routes the token to “E” (in this case “PF” 
is executed once) or to “D” (“F” is executed twice). While this solution may work, 
we have the problem that we do not know whether activity “F”’ will be executed 
once or twice, and we may actually not want to execute it twice. Moreover, if this 
is the case, we would signal that the process has completed twice, since the end 
event following “F” will receive two tokens. And this, again, is something we want 
to avoid. 
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The only join type left to try is the OR-join. An OR-join will wait for all incoming 
active branches to complete. If the XOR-split routes control to “E”’, the OR-join will 
not wait for a token from the branch bearing activity “D”, since this will never arrive. 
Thus, it will proceed once the token from activity “C” arrives. On the other hand, if 
the XOR-split routes control to “D”, the OR-join will wait for a token to also arrive 
from this branch, and once both tokens have arrived, it will merge them into one and 
send this token out, so that “F” can be executed once and the process can complete 
normally. 


Question When should we use an OR-join? 


Since the OR-join semantics is not simple, the presence of this element in a 
model may confuse the reader. Thus, we suggest to use it only when it is strictly 
required. Clearly, it is easy to see that an OR-join must be used whenever we need 
to synchronize control from a preceding OR-split. Similarly, we should use an AND- 
join to synchronize control from a preceding AND-split and an XOR-join to merge 
a set of branches that are mutually exclusive. In other cases the model will not have 
a lean structure like the examples in Fig. 3.8 or 3.10, where the model is made up of 
nested blocks each delimited by a split and a join of the same type. The model may 
rather look like that in Fig. 3.11, where there can be entry points into, or exist points 
from a block-structure. In these cases play the token game to understand the correct 
join type. Start with an XOR-join; next try an AND-join and if both gateways lead 
to incorrect models use the OR-join which will work for sure. 

Now that we have learned the three core gateways, let us use them to extend 
the order fulfillment process. Assume that if the product is not in stock, it can be 
manufactured. In this way, an order can never be rejected. 


Example 3.6 


If the product requested is not in stock, it needs to be manufactured before the order handling 
can continue. To manufacture a product, the required raw materials have to be ordered. Two 
preferred suppliers provide different types of raw material. Depending on the product to 
be manufactured, raw materials may be ordered from either Supplier 1 or Supplier 2, or 
from both. Once the raw materials are available, the product can be manufactured and the 
order can be confirmed. On the other hand, if the product is in stock, it is retrieved from the 
warehouse before confirming the order. Then the process continues normally. 


The model for this extended order fulfillment process is shown in Fig. 3.12. 


Exercise 3.3 Model the following fragment of a business process for assessing loan 
applications. 


A loan application may be coupled with a home insurance which is offered at discounted 
prices. The applicant may express their interest in a home insurance plan at the time of 
submitting their loan application to the loan provider. Based on this information, if the 
loan application is approved, the loan provider may either only send an acceptance pack 
to the applicant, or also send a home insurance quote. The process then continues with the 
verification of the repayment agreement. 


3.2 Branching and Merging 77 


Request Obtain 
raw materials raw materials 
from from 
Supplier 1 Supplier 1 
Request Obtain 
raw materials raw materials 
from from 
Supplier 2 Supplier 2 


raw materials 
provided by 
Supplier 1 


Check 
raw materials Manutectite 
availability Pl 


raw materials 
provided by 
Supplier 2 


product 
not in stock 


Check 
stock 
availability 
Purchase 
order 
received 
————— th 


Get 
shipment 
address 


product 
in stock Shi 


product 


Retrieve 
product 
from 
warehouse 


Confirm 
order 


Archive 
order 


Order 
fulfilled 


mit 


Emi Receive 
invoice 


payment 


Fig. 3.12 The order fulfillment process diagram with product manufacturing 


3.2.4 Rework and Repetition 


So far we have seen structures that are linear, i.e. each activity is performed at most 
once. However, sometimes we may require to repeat one or several activities, for 
instance because of a failed check. 


Example 3.7 


In the treasury minister’s office, once a ministerial inquiry has been received, it is first 
registered into the system. Then the inquiry is investigated so that a ministerial response 
can be prepared. The finalization of a response includes the preparation of the response 
itself by the cabinet officer and the review of the response by the principal registrar. If the 
registrar does not approve the response, the latter needs to be prepared again by the cabinet 
officer for review. The process finishes only once the response has been approved. 


To model rework or repetition we first need to identify the activities, or more 
in general the fragment of the process, that can be repeated. In our example this 
consists of the sequence of activities “Prepare ministerial response” and “Review 
ministerial response”. Let us call this our repetition block. The property of a repeti- 
tion block is that the last of its activities must be a decision activity. In fact, this will 
allow us to decide whether to go back before the repetition block starts, so that this 
can be repeated, or to continue with the rest of the process. As such, this decision 
activity should have two outcomes. In our example the decision activity is “Review 
ministerial response” and its outcomes are: “response approved” (in this case we 
continue with the process) and “response not approved” (we go back). To model 
these two outcomes, we use an XOR-split with two outgoing branches: one which 
allows us to continue with the rest of the process (in our example, this is simply 
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Fig. 3.13. A process model for addressing ministerial correspondence 


the end event “Ministerial correspondence addressed”’), the other which goes back 
to before activity “Prepare ministerial response”. We use an XOR-join to reconnect 
this branch to the point of the process model just before the repetition block. The 
model for our example is illustrated in Fig. 3.13. 


Question Why do we need to merge the loopback branch of a repetition block with 
an XOR-join? 


The reason for using an XOR-join is that this gateway has a very simple seman- 
tics: it moves any token it receives in its input arc to its output arc, which is what 
we need in this case. In fact, if we merged the loopback branch with the rest of the 
model using an AND-join we would deadlock since this gateway would try to syn- 
chronize the two incoming branches when we know that only one of them can be 
active at a time: if we were looping we would receive the token from the loopback 
branch; otherwise we would receive it from the other branch indicating that we are 
entering the repetition block for the first time. An OR-join would work but is an 
overkill since we know that only one branch will be active at a time. 


Exercise 3.4 Model the following fragment of a business process for assessing loan 
applications. 


Once a loan application is received by the loan provider, and before proceeding with its 
assessment, the application itself needs to be checked for completeness. If the application is 
incomplete, it is returned to the applicant, so that they can fill out the missing information 
and send it back to the loan provider. This process is repeated until the application is found 
complete. 


We have learned how to combine activities, events, and gateways to model basic 
business processes. For each such element we have showed its graphical represen- 
tation, the rules for combining it with other modeling elements and explained its 
behavior in terms of token rules. All these aspects fall under the term components of 
a modeling language. If you want to know more about this topic, you can read the 
box “Components of a modeling language”. 


COMPONENTS OF A MODELING LANGUAGE 
A modeling language consists of three parts: syntax, semantics, and notation. 
The syntax provides a set of modeling elements and a set of rules to govern 
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how these elements can be combined. The semantics bind the syntactical ele- 
ments and their textual descriptions to a precise meaning. The notation defines 
a set of graphical symbols for the visualization of the elements. 

For example, the BPMN syntax includes activities, events, gateways, and 
sequence flows. An example of syntactical rule is that start events only have 
outgoing sequence flows whereas end events only have incoming sequence 
flows. The BPMN semantics describes which kind of behavior is represented 
by the various elements. In essence, this relates to the question how the ele- 
ments can be executed in terms of token flow. For example, an AND-join has 
to wait for all incoming branches to complete before it can pass control to its 
outgoing branch. An example of BPMN notation is the use of labeled rounded 
boxes to depict activities. 


3.3 Information Artifacts 


As shown in Chap. 2, a business process entails different organizational aspects 
such as functions, business artifacts, humans, and software systems. These aspects 
are captured by different process modeling perspectives. So far we have seen the 
functional perspective, which indicates what activities should happen in the pro- 
cess, and the control-flow perspective, which indicates when activities and events 
should occur. Another important perspective that we ought to consider when model- 
ing business processes is the data perspective. The data perspective indicates which 
information artifacts (e.g. business documents, files) are required to perform an ac- 
tivity and which ones are produced as a result of performing an activity. 

Let us enrich the order fulfillment process of Example 3.6 with artifacts. Let us 
start by identifying the artifacts that each activity requires in order to be executed, 
and those that each activity creates as a result of its execution. For example, the first 
activity of the order fulfillment process is “Check stock availability”. This requires 
a Purchase order as input in order to check whether or not the ordered product is 
in stock. This artifact is also required by activity “Check raw materials availability” 
should the product be manufactured. Artifacts like Purchase order are called data 
objects in BPMN. Data objects represent information flowing in and out of activi- 
ties; they can be physical artifacts such as an invoice or a letter on a piece of paper, 
or electronic artifacts such as an e-mail or a file. We depict them as a document with 
the upper-right corner folded over, and link them to activities with a dotted arrow 
with an open arrowhead (called data association in BPMN). Figure 3.14 shows the 
data objects involved in the order fulfillment process model. 

We use the direction of the data association to establish whether a data object is 
an input or output for a given activity. An incoming association, like the one used 
from Purchase order to activity “Check stock availability”, indicates that Purchase 
order is an input object for this activity; an outgoing association, like the one used 
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Fig. 3.14 The order fulfillment example with artifacts 
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from activity “Obtain raw materials from Supplier 1” to Raw materials, indicates 
that Raw materials is an output object for this activity. To avoid cluttering the dia- 
gram with data associations that cross sequence flows, we may repeat a data object 
multiple times within the same process model. However, all occurrences of a given 
object do conceptually refer to the same artifact. For example, in Fig. 3.14 Purchase 
order is repeated twice as input to “Check stock availability” and to “Confirm order” 
since these two activities are far away from each other in terms of model layout. 
Often the output from an activity coincides with the input to a subsequent activity. 
For example, once Raw materials have been obtained, these are used by activity 
“Manufacture product” to create a Product. The Product in turn is packaged and 
sent to the customer by activity “Ship product”. Effectively, data objects allow us 
to model the information flow between process activities. Bear in mind, however, 
that data objects and their associations with activities cannot replace the sequence 
flow. In other words, even if an object is passed from an activity A to an activity B, 
we still need to model the sequence flow from A to B. A shorthand notation for 
passing an object from an activity to the other is by directly connecting the data 
object to the sequence flow between two consecutive activities via an undirected 
association. See for example the Shipment address being passed from activity “Get 


3.3. Information Artifacts 81 


shipment address” to activity “Ship product”, which is a shorthand for indicating 
that Shipment address is an output of “Get shipment address” and an input to “Ship 
product”. 

Sometimes we may need to represent the state of a data object. For instance, 
activity “Confirm order” takes a Purchase order as input, and returns a “confirmed” 
Purchase order as output: input and output objects are the same, but the object’s 
state has changed to “confirmed”. Similarly, activity “Receive payment” takes as 
input a “confirmed” Purchase order and transforms it into a “paid” Purchase order. 
An object can go through a number of states, e.g. an invoice is first “opened”, then 
“approved” or “rejected” and finally “archived”. Indicating data objects’ states is 
optional: we can do so by appending the name of the state between square brackets 
to a data object’s label, e.g. “Purchase Order [confirmed]’, “Product [packaged]”’. 

A data store is a place containing data objects that need to be persisted beyond 
the duration of a process instance, e.g. a database for electronic artifacts or a fil- 
ing cabinet for physical ones. Process activities can read/write data objects from/to 
data stores. For example, activity “Check stock availability” retrieves the Stock lev- 
els for the ordered product from the Warehouse database, which contains Stock 
level information for the various Products. Similarly, activity “Check raw materials 
availability” consults the Suppliers catalog to check which Supplier to contact. The 
Warehouse database or the Supplier catalog are examples of data stores used as input 
to activities. An example of data store employed as output is the Orders database, 
which is used by activity “Archive order” to store the confirmed Purchase order. In 
this way, the order just archived will be available for other business processes within 
the same organization, e.g. for a business process that handles requests for prod- 
uct returns. Data stores are represented as an empty cylinder (the typical database 
symbol) with a triple upper border. Similar to data objects, they are connected to 
activities via data associations. 


Question Do data objects affect the token flow? 


Input data objects are required for an activity to be executed. Even if a token 
is available on the incoming arc of that activity, the latter cannot be executed until 
all input data objects are also available. A data object is available if it has been 
created as a result of completing a preceding activity (whose output was the data 
object itself), or because it is an input to the whole process (like Purchase order). 
Output data objects only affect the token flow indirectly, i.e. when they are used by 
subsequent activities. 


Question Do we always need to model data objects? 


Data objects help the reader understand the flow of business data from one activ- 
ity to the other. However, the price to pay is an increased complexity of the diagram. 
Thus, we suggest to use them only when they are needed for a specific purpose, e.g. 
to highlight potential issues in the process under analysis (cf. Chaps. 6 and 7) or for 
automation (cf. Chap. 9). 
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Sometimes we may need to provide additional information to the process model 
reader, for the sake of improving the understanding of the model. For example, in 
the order fulfillment process we may want to specify that activity “Ship product” 
includes the packaging of the product. Also, we may want to clarify what business 
tule is followed behind the choice of raw materials from Suppliers. Such additional 
information can be provided via text annotations. An annotation is depicted as an 
open-ended rectangle encapsulating the text of the annotation, and is linked to a 
process modeling element via a dotted line (called association)—see Fig. 3.14 for 
an example. Text annotations do not bear any semantics, thus they do not affect the 
flow of tokens through the process model. 


Exercise 3.5 Put together the four fragments of the loan assessment process that 
you created in Exercises 3.1—3.4. 


Hint Look at the labels of the start/end events to understand the order dependencies 
among the various fragments. Then extend the resulting model by adding all the 
required artifacts. Moreover, attach annotations to specify the business rules behind 
(i) checking an application completeness, (ii) assessing an application eligibility, 
and (iii) verifying a repayment agreement. 


3.4 Resources 


A further aspect we need to consider when modeling business processes is the re- 
source perspective. This perspective, also called the organizational perspective, in- 
dicates who or what performs which activity. Resource is a generic term to refer to 
anyone or anything involved in the performance of a process activity. A resource 
can be: 


e A process participant, i.e. an individual person like the employee John Smith. 
e A software system, for example a server or a software application. 
e An equipment, such as a printer or a manufacturing plant. 


We distinguish between active resources, i.e. resources that can autonomously 
perform an activity, and passive resources, i.e. resources that are merely involved in 
the performance of an activity. For example, a photocopier is used by a participant to 
make a copy of a document, but it is the participant who performs the photocopying 
activity. So, the photocopier is a passive resource while the participant is an active 
resource. A bulldozer is another example of a passive resource since it is the driver 
who performs the activity in which the bulldozer is used. 

The resource perspective of a process is interested in active resources, so from 
now on with the term “resource” we refer to an “active resource”. 

Frequently, in a process model we do not explicitly refer to one resource at a 
time, like for example an employee John Smith, but instead we refer to a group of 
resources that are interchangeable in the sense that any member of the group can 
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perform a given activity. Such groups are called resource classes. Examples are a 
whole organization, an organizational unit or a role.! 
Let us examine the resources involved in our order fulfillment example. 


Example 3.8 


The order fulfillment process is carried out by a seller’s organization which includes two de- 
partments: the sales department and the warehouse & distribution department. The purchase 
order received by warehouse & distribution is checked against the stock. This operation is 
carried out automatically by the ERP system of warehouse & distribution, which queries 
the warehouse database. If the product is in stock, it is retrieved from the warehouse be- 
fore sales confirm the order. Next sales emit an invoice and wait for the payment, while the 
product is shipped from within warehouse & distribution. The process completes with the 
order archival in the sales department. If the product is not in stock, the ERP system within 
warehouse & distribution checks the raw materials availability by accessing the suppliers 
catalog. Once the raw materials have been obtained the warehouse & distribution depart- 
ment takes care of manufacturing the product. The process completes with the purchase 
order being confirmed and archived by the sales department. 


BPMN provides two constructs to model resource aspects: pools and lanes. Pools 
are generally used to model resource classes, lanes are used to partition a pool into 
sub-classes or single resources. There are no constraints as to what specific resource 
type a pool or a lane should model. We would typically use a pool to model a busi- 
ness party like a whole organization such as the seller in our example, and a lane 
to model a department, unit, team or software system/equipment within that orga- 
nization. In our example, we partition the Seller pool into two lanes: one for the 
warehouse & distribution department, the other for the sales department. 

Lanes can be nested within each other in multiple levels. For example, if we 
need to model both a department and the roles within that department, we can use 
one outer lane for the department, and one inner lane for each role. In the order 
fulfillment example we nest a lane within Warehouse & Distribution to represent 
the ERP System within that department. 

Pools and lanes are depicted as rectangles within which we can place activities, 
events, gateways, and data objects. Typically, we model these rectangles horizon- 
tally, though modeling them vertically is also possible. The name of the pool/lane 
is shown vertically on the left-hand side of a horizontal rectangle (or horizontally if 
the pool/lane is vertical); for pools, and for lanes containing nested lanes , the name 
is enclosed in a band. Figure 3.15 shows the revised order fulfillment example with 
resource aspects. 

It is important to place an activity within the right lane. For example, we placed 
activity “Check stock availability” under the ERP System lane of Warehouse & 
Distribution to indicate that this activity is carried out automatically by the ERP 
system of that department. It is also important to place events properly within lanes. 
In our example we put event “Purchase order received” under the ERP system lane to 
indicate that the process starts within the ERP system of Warehouse & Distribution, 


'In BPMN the term “participant” is used in a broad sense as a synonym of resource class, though 
in this book we do not adopt this definition. 
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Fig. 3.15 The order fulfillment example with resource information 


3.4 Resources 85 


while we put event “Order fulfilled” under the Sales pool to indicate that the process 
completes in the sales department. It is not relevant where data objects are put, as 
they depend on the activities they are linked to. As per gateways, we need to place 
those modeling (X)OR-splits under the same lane as the preceding decision activity 
has been put in. On the other hand, it is irrelevant where we place an AND-split 
and all join gateways, since these elements are passive in the sense that they behave 
according to their context. 


We may organize lanes within a pool in a matrix when we need to model com- 
plex organizational structures. For example, if we have an organization where roles 
span different departments, we may use horizontal lanes to model the various de- 
partments, and vertical lanes to model the roles within these departments. Bear in 
mind, however, that in BPMN each activity can be performed by one resource only. 
Thus, if an activity sits in the intersection of a horizontal lane with a vertical lane, it 
will be performed by the resource that fulfills the characteristics of both lanes, e.g. 
a resource that has that role and belongs to that department. 


Exercise 3.6 Extend the business process for assessing loan applications that you 
created in Exercise 3.5 by considering the following resource aspects. 


The process for assessing loan applications is executed by four roles within the loan 
provider: a financial officer takes care of checking the applicant’s credit history; a prop- 
erty appraiser is responsible for appraising the property; an insurance sales representative 
sends the home insurance quote to the applicant if this is required. All other activities are 
performed by the loan officer who is the main point of contact with the applicant. 


Often there is more than one business party participating in the same business 
process. For example, in the order fulfillment process there are four parties: the 
seller, the customer and the two suppliers. 

Each party can be modeled by a pool. In our example we can thus use one pool 
for the customer, one for the seller and one for each supplier. Each of these pools 
will contain the activities, events, gateways, and data objects that model the specific 
portion of the business process occurring at that organization. Or to put it differently, 
each pool will model the same business process from the perspective of a specific 
organization. For example, event “Purchase order received” which sits in the Sales 
pool, will have a corresponding activity “Submit purchase order’ occurring in the 
Customer pool. Similarly, activity “Ship product” from Sales will have a counter- 
part activity “Receive product” in the Customer pool. So, how can we model the 
interactions among the pools of two collaborating organizations? We cannot use the 
sequence flow to connect activities that belong to different pools since the sequence 
flow cannot cross the boundary of a pool. For this, we need to use a specific element 
called message flow. 

A message flow represents the flow of information between two separate resource 
classes (pools). It is depicted as a dashed line which starts with an empty circle 
and ends with an empty arrowhead, and bears a label indicating the content of the 
message, e.g. a fax, a purchase order, but also a letter or a phone call. That is, the 
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message flow models any type of communication between two organizations, no 
matter if this is electronic like sending a purchase order via e-mail or transmitting a 
fax, or manual like making a phone call or handing over a letter on paper. 

Figure 3.16 shows the complete order fulfillment process model including the 
pools for the customer and the two suppliers. Here we can see that message flows 
are labeled with the piece of information they carry, e.g. “Raw materials” or “Ship- 
ment address”. An incoming message flow may lead to the creation of a data ob- 
ject by the activity that receives the message. For example, the message flow “Raw 
materials” is received by activity “Obtain raw materials from Supplier 1” which 
then creates the data object “Raw materials”. This is also the case of the purchase 
order, which is generated by the start event “Purchase order received” from the 
content of the incoming message flow. We do not need to create a data object for 
each incoming message flow, only when the information carried by the message is 
needed elsewhere in the process. In our case, “Raw materials” is consumed by ac- 
tivity “Manufacture product” so we need to represent it as a data object. Similarly, 
we do not need to explicitly represent the data object that goes into an outgoing 
message if this data object is not needed elsewhere in the process. For example, ac- 
tivity “Emit invoice” generates an invoice which is sent to the customer, but there 
is no data object “Invoice” since this is not consumed by any activity in the Seller 
pool. 

A BPMN diagram that features two or more pools is called collaboration dia- 
gram. Figure 3.16 shows different uses of a pool in a collaboration diagram. A pool 
like that for the seller is called private process, or white box pool, since it shows 
how effectively the seller organization participates in the order fulfillment process 
in terms of activities, events, gateways, and data objects. On the contrary, a pool 
like that for the customer and the two suppliers is called public process, or black 
box pool, since it hides how these organizations actually participate in the order 
fulfillment process. In order to save space, we can represent a black box with a 
collapsed pool, which is an empty rectangle bearing the name of the pool in the 
middle. 


Question Black box or white box? 


Modeling a pool as a white box or as a black box is a matter of relevance. When 
working on a collaboration diagram, an organization may decide whether or not 
to expose their internal behavior depending on the requirements of the project at 
hand. For example, if we are modeling the order fulfillment process from the seller’s 
perspective, it may be relevant to expose the business process of the seller only, 
but not that of the customer and the suppliers. That is, the internal behavior of the 
customer and that of the suppliers are not relevant for the sake of understanding 
how the seller should fulfill purchase orders, and as such they can be hidden. On 
the other hand, if we need to improve the way the seller fulfills purchase orders, we 
may also want to know what it takes for a supplier to provide raw materials, as a 
delay in the provision of raw materials will slow down the product manufacturing 
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Fig. 3.16 Collaboration diagram between a seller, a customer and two suppliers 
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at the seller’s side. In this case, we should also represent the suppliers using white 
box pools. 

The type of pool affects the way we use the message flow to connect to the 
pool. Accordingly, a message flow may cross the boundary of a white box pool 
and connect directly to an activity or event within that pool, like the Purchase order 
message which is incident to the start event in the Seller pool. On the other hand, 
since a black box pool is empty, message flows must stop at the boundary or emanate 
from the boundary of a black box pool. Bear in mind that a message flow is only 
used to connect two pools and never to connect two activities within the same pool. 
For that, we use a sequence flow. 

An activity that is the source of a message—such as “Emit invoice” in the Seller 
pool—is called a send activity. The message is sent upon completion of the activity’s 
execution. On the other hand, an activity that receives a message—such as “Get 
shipping address”—is a receive activity.’ The execution of such an activity will not 
start until the incoming message is available. An activity can act as both a receive 
and a send activity when it has both an incoming and outgoing message flow, e.g. 
“Make payment”. The execution of this activity will start when both the control-flow 
token and the incoming message are available. Upon completion of the activity, a 
control-flow token will be put on the output arc and the outgoing message will be 
sent out. Finally, when a message flow is incident to a start event like “Purchase 
order received”, we need to mark this event with a light envelope (see Fig. 3.16). 
This event type is called message event. A message event can be linked to an output 
data object in order to store the content of the incoming message. We will learn 
more about events in the next chapter. 


Exercise 3.7 Extend the model of Exercise 3.6 by representing the interactions be- 
tween the loan provider and the applicant. 


In the order fulfillment example we used pools to represent business parties and 
lanes to represent the departments and systems within the sales organization. This is 
because we wanted to focus on the interactions between the seller, the customer and 
the two suppliers. As mentioned before, this is the typical use for pools and lanes. 
However, since BPMN does not prescribe what specific resource types should be 
associated with pools and lanes, we may use these elements differently. For exam- 
ple, if the focus is on the interactions between the departments of an organization, 
we can model each department with a pool, and use lanes to partition the depart- 
ments, e.g. in units or roles. In any case, we should avoid to use pools and lanes 
to capture participants by their names since individuals tend to change frequently 
within an organization; rather, we should use the participant’s role, e.g. financial 
officer. On the other hand, we can use pools and lanes to represent specific software 
systems or equipments, e.g. an ERP system, since these change less frequently in an 
organization. 


More specifically, “Emit invoice” is a send task and “Get shipping address” is a receive task. The 
distinction between activity and task will be discussed in Chap. 4. 
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3.5 Recap 


At the end of this chapter, we should be able to understand and produce basic pro- 
cess models in BPMN. A basic BPMN model includes simple activities, events, 
gateways, data objects, pools, and lanes. Activities capture units of work within a 
process. Events define the start and end of a process, and signal something that hap- 
pens during the execution of it. Gateways model exclusive and inclusive decisions, 
merges, parallelism and synchronization, and repetition. We studied the difference 
between process model and process instance. A process model depicts all the possi- 
ble ways a given business process can be executed, while a process instance captures 
one specific process execution out of all possible ones. The progress, or state, of a 
process instance is represented by tokens. Using tokens we can define the behavior 
of gateways. 

We also learned how to use data objects to model the information flow between 
activities and events. A data object captures a physical or an electronic artifact re- 
quired to execute an activity or trigger an event, or that results from the execution 
of an activity or an event occurrence. Data objects can be stored in a data store 
like a database or file cabinet such that they can be persisted beyond the process 
instance where they are created. Furthermore, we saw how pools and lanes can be 
used to model both human and non-human resources that perform process activi- 
ties. Pools generally model resource classes while lanes are used to partition pools. 
The interaction between pools is captured by message flows. Message flows can be 
directly attached to the boundary of a pool, should the details of the interaction not 
be relevant. 

Activities, events, gateways, artifacts, and resources belong to the main model- 
ing perspectives of a business process. The functional perspective captures the ac- 
tivities that are performed in a business process while the control-flow perspective 
combines these activities and related events in a given order. The data perspective 
covers the artifacts manipulated in the process while the resource perspective covers 
the resources that perform the various activities. In the next chapter, we will learn 
how to model complex business processes by delving into the various extensions of 
the core BPMN elements that we presented here. 
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Solution 3.6 See the Loan Provider pool in the model of Solution 3.7. 
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3.7 Further Exercises 


Exercise 3.8 What types of splits and joins can we model in a process? Make an 
example for each of them using the security check at an airport as a scenario. 


Exercise 3.9 Describe the following process model. 
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Exercise 3.10 Model the following business process for handling downpayments. 


The process for handling downpayments starts when a request for payment has been ap- 
proved. It involves entering the downpayment request into the system, the automatic sub- 
sequent payment, emission of the direct invoice and the clearance of the vendor line items. 
The clearing of the vendor line items can result in a debit or credit balance. In case of debit 
balance, the arrears are processed, otherwise the remaining balance is paid. 


Exercise 3.11 Model the following business process for assessing credit risks. 


When a new credit request is received, the risk is assessed. If the risk is above a threshold, 
an advanced risk assessment needs to be carried out, otherwise a simple risk assessment will 
suffice. Once the assessment has been completed, the customer is notified with the result of 
the assessment and meantime the disbursement is organized. For simplicity, assume that the 
result of an assessment is always positive. 


Exercise 3.12 Model the following fragment of a business process for insurance 
claims. 


After a claim is registered, it is examined by a claims officer who then writes a settlement 
recommendation. This recommendation is then checked by a senior claims officer who may 
mark the claim as “OK” or “Not OK”. If the claim is marked as “Not OK’, it is sent back 
to the claims officer and the recommendation is repeated. If the claim is “OK”, the claim 
handling process proceeds. 


Exercise 3.13 Model the control flow of the following business process for damage 
compensation. 


If a tenant is evicted because of damages to the premises, a process needs to be started by the 
tribunal in order to hold a hearing to assess the amount of compensation the tenant owes the 
owner of the premises. This process starts when a cashier of the tribunal receives a request 
for compensation from the owner. The cashier then retrieves the file for those particular 
premises and checks that both the request is acceptable for filing, and compliant with the 
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description of the premises on file. Setting a hearing date incurs fees to the owner. It may be 
that the owner has already paid the fees with the request, in which case the cashier allocates 
a hearing date and the process completes. It may be that additional fees are required, but the 
owner has already paid also those fees. In this case the cashier generates a receipt for the 
additional fees and proceeds with allocating the hearing date. Finally, if the owner has not 
paid the required fees, the cashier produces a fees notice and waits for the owner to pay the 
fees before reassessing the document compliance. 


Exercise 3.14 Can the process model below execute correctly? If not, how can it 
be fixed without affecting the cycle, i.e. such that “F’, “G’, and “E” all remain in 
the cycle? 


Exercise 3.15 Write a BPMN model for the process described in Exercise 1.1. 
Make sure to include artifacts and annotations where appropriate. 


Exercise 3.16 Extend the model of Exercise 3.13 by adding the artifacts that are 
manipulated. 


Exercise 3.17 Extend the model of Exercise 3.16 by adding the involved resources. 
Is there any non-human resource? 


Exercise 3.18 Model the following business process. Use gateways and data objects 
where needed. 


In a court each morning the files that have yet to be processed are checked to make sure 
they are in order for the court hearing that day. If some files are missing a search is initiated, 
otherwise the files can be physically tracked to the intended location. Once all the files are 
ready, these are handed to the Associate; meantime the judge’s lawlist is distributed to the 
relevant people. Afterwards, the directions hearings are conducted. 


Exercise 3.19 Model the following business process. Use pools/lanes where 
needed. 


The motor claim handling process starts when a customer submits a claim with the relevant 
documentation. The notification department at the car insurer checks the documents upon 
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completeness and registers the claim. Next, the Handling department picks up the claim 
and checks the insurance. Then, an assessment is performed. If the assessment is positive, 
a Garage is phoned to authorize the repairs and the payment is scheduled (in this order). 
Otherwise, the claim is rejected. In any case (whether the outcome is positive or negative), 
a letter is sent to the customer and the process is considered to be complete. 


Exercise 3.20 Model the following business process. Use pools/lanes where 
needed. 


When a claim is received, a claims officer first checks if the claimant is insured. If not, the 
claimant is informed that the claim must be rejected by sending an automatic notification via 
an SAP system. Otherwise, a senior claims officer evaluates the severity of the claim. Based 
on the outcome (simple or complex claims), the relevant forms are sent to the claimant, 
again using the SAP system. Once the forms are returned, they are checked for completeness 
by the claims officer. If the forms provide all relevant details, the claim is registered in the 
claims management system, and the process ends. Otherwise, the claimant is informed to 
update the forms via the SAP system. Upon reception of the updated forms, they are checked 
again by the claims officer to see if the details have been provided, and so on. 


3.8 Further Reading 


In this chapter we presented the basics of process modeling through the BPMN 
language. Other mainstream languages that can be used to model business processes 
are UML Activity Diagrams (UML ADs), Event-driven Process Chains (EPCs) and 
Web Services Business Process Execution Language (WS-BPEL). UML ADs are 
another OMG standard [60]. They are mainly employed in software engineering 
where they can be used to describe software behavior and linked to other UML 
diagram types, e.g. class diagrams, to generate software code. UML ADs offer a 
subset of the modeling elements present in BPMN. For example, constructs like the 
OR-join are not supported. A good overview of this language and its application to 
business process modeling is provided in [16]. 

EPCs were initially developed for the design of the SAP R/3 reference process 
model [9]. They obtained a widespread adoption by various organizations when they 
became the core modeling language of the ARIS toolset [12, 82]. Later, they were 
used by other vendors for the design of SAP-independent reference models such as 
ITIL and SCOR. The EPC language includes modeling elements corresponding to 
BPMN activities, AND, XOR and OR gateways, untyped events and data objects. 
An introduction to EPCs is provided in [50]. 

WS-BPEL (BPEL for short) version 2.0 [3] is a standard of the Organization for 
the Advancement of Structured Information Standards (OASIS). A good overview 
of BPEL is provided in [65]. BPEL is a language for process execution which re- 
lies on Web service technology to achieve inter-process communication. A mapping 
from BPMN to BPEL constructs is available in the BPMN specification [61]. How- 
ever, this mapping is not complete since BPEL offers a restricted set of constructs 
compared to BPMN, and is essentially a block-oriented language, while BPMN is 
graph-oriented. BPEL is structured in blocks which need to be properly nested and 
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cannot overlap. A block is made up of a single entry node and a single exit node 
which matches the type of the entry node and collects all the outgoing branches 
from the entry node. For example, if the entry node is an AND-split, the exit node 
must be an AND-join. Moreover, BPEL does not feature a standard notation, since 
this was deemed to be out of scope by OASIS, though various vendors provide pro- 
prietary notations for this language. While BPMN 1.2 aimed to be the conceptual 
counterpart of BPEL, and mappings were thus available to move from the former to 
the latter language, BPMN 2.0 can also be used to specify executable processes (see 
Chap. 9). Thus BPMN 2.0 aims to replace BPEL in this respect. 

Other process modeling languages originate from research efforts. Two of them 
are Workflow nets and Yet Another Workflow Language (YAWL). Workflow nets 
are an extension of Petri nets to model business processes. Their syntax is purpose- 
fully simple and revolves around two elements: places and transitions. The former 
roughly correspond to BPMN events, while the latter to BPMN activities. A good 
presentation of Workflow nets is provided in [95]. 

YAWL is a successor of Workflow nets in that it adds specific constructs to cap- 
ture the OR-join behavior, multi-instance activities, sub-processes and cancellation 
regions. YAWL retains the simplicity and intuitiveness of Workflow nets, though it 
provides a much more expressive language. YAWL and its supporting environment 
are presented in detail in [92]. 

A comparison of the above languages in terms of their expressiveness along the 
control-flow, data and resource perspectives can be found in the Workflow Patterns 
Initiative website [108]. Over time this initiative has collected a repository of work- 
flow patterns, i.e. recurring process behavior as it has been observed from a thor- 
ough analysis of various process modeling languages and supporting tools. Various 
languages and tools have been compared based on their support for such patterns. 


Chapter 4 
Advanced Process Modeling 


The sciences do not try to explain, they hardly even try to 
interpret, they mainly make models. 
John von Neumann (1903-1957) 


In this chapter we will learn how to model complex business processes with BPMN. 
The constructs presented in this chapter build on top of the knowledge acquired 
in Chap. 3. In particular, we will expand on activities, events and gateways. We 
will learn how to use activities to model sub-processes and how to reuse these sub- 
processes across different processes. We will also extend activities to model more 
sophisticated forms of rework and repetition. As per events, we will expand on mes- 
sage events, present temporal events and show how race conditions can be modeled 
among these event types via a new type of gateway. We will also learn how to use 
events to handle business process exceptions. Finally, we will show how a collabo- 
ration diagram can be abstracted into a choreography diagram that only focuses on 
the interactions between the involved business parties. 


4.1 Process Decomposition 


When capturing complex business processes, the resulting process model may be 
too large to be understood at once. Take the order fulfillment process model in 
Fig. 3.12. While the scenario at hand is still relatively simple, this model already 
contains 14 activities, six gateways and two events. As we add data objects and mes- 
sage flows, the model gets larger and so harder to understand (see e.g. Fig. 3.16). To 
improve its readability, we can simplify the process by hiding certain parts within 
a sub-process. A sub-process represents a self-contained, composite activity that 
can be broken down into smaller units of work. Conversely, an atomic activity, also 
called task, is an activity capturing a unit of work that cannot be further broken 
down. 

In order to use a sub-process, we first need to identify groups of related activities, 
i.e. those activities which together achieve a particular goal or generate a particu- 
lar outcome in the process model under analysis. In our order fulfillment example, 
we can see that the activities “Check raw materials availability” and “Purchase raw 


M. Dumas et al., Fundamentals of Business Process Management, 97 
DOI 10.1007/978-3-642-33143-5_4, © Springer-Verlag Berlin Heidelberg 2013 


98 4 Advanced Process Modeling 


Obtain 
raw materials 
from 
Supplier 1 


Obtain 
raw materials 


Acquire raw materials 


Request 
raw materials 


raw materials 
provided by 
Supplier 1 


rom 
Supplier 1 


Check 
raw materials 
availability 


Manufacture 
product 


Raw 
materials 
acquired 


Stock 
availability Request 
checked raw materials 


raw materials 
provided by rom rom 
Supplier 2 Supplier 2 Supplier 2 


product not 
in stock 


Check 


stock 
availability 


Purchase 
order 
received 
product 
in stock 


Ship and invoice 


Retrieve 
product from 
warehouse 


Get 
shipment 


Ship 
address breducs 
Emit Receive 
invoice payment 


Fig. 4.1 Identifying sub-processes in the order fulfillment process of Fig. 3.12 
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materials from Supplier 1(2)”, lead together to the acquisition of raw materials. 
Thus these activities, and their connecting gateways, can be encapsulated in a sub- 
process. In other words, they can be seen as the internal steps of a macro-activity 
called “Acquire raw materials”. Similarly, the two parallel branches for shipping and 
invoicing the order can be grouped under another sub-process activity called “Ship 
and invoice”. Figure 4.1 illustrates the resulting model, where the above activities 
have been enclosed in two sub-process activities. We represent such activities with 
a large rounded box which encloses the internal steps. As we can observe from 
Fig. 4.1, we also added a start event and an end event inside each sub-process activ- 
ity, to explicitly indicate when the sub-process starts and completes. 

Recall that our initial objective was to simplify a process model. Once we have 
identified the boundaries of the sub-processes, we can simplify the model by hid- 
ing the content of its sub-processes, as shown in Fig. 4.2. This is done by replacing 
the macro-activity representing the sub-process with a standard-size activity. We 
indicate that this activity hides a sub-process by marking it with a small square 
with a plus sign (+) inside (like if we could expand the content of that activity 
by pressing the plus button). This operation is called collapsing a sub-process. By 
collapsing a sub-process we reduce the total number of activities (the order ful- 
fillment process has only six activities now), thus improving the model readabil- 
ity. In BPMN, a sub-process which hides its internal steps is called collapsed sub- 
process, as opposed to an expanded sub-process which shows its internal steps (as 
in Fig. 4.1). 
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Fig. 4.2 A simplified version of the order fulfillment process after hiding the content of its sub- 
processes 


Exercise 4.1 Identify suitable sub-processes in the process for assessing loan ap- 
plications modeled in Exercise 3.5. 


Hint Use the building blocks that you created throughout Exercises 3.1—3.4. 


Collapsing a sub-process does not imply losing its content. The sub-process 
is still there, just defined at an abstraction level below. In fact, we can nest sub- 
processes in multiple levels, so as to decompose a process model hierarchically. An 
example is shown in Fig. 4.3, which models a business process for disbursing home 
loans. In the first level we identified two sub-processes: one for checking the appli- 
cant’s liability, the other for signing the loan. In the second level, we factored out 
the scheduling of the loan disbursement within the process for signing loans into a 
separate sub-process. 

As we go down the hierarchical decomposition of a process model, we can add 
more details. For example, we may establish a convention that at the top level we 
only model core business activities, at the second level we add decision points, and 
so on all the way down to modeling exceptions and details that are only relevant for 
process automation. 


Question When should we decompose a process model into sub-processes? 


We should use sub-processes whenever a model becomes too large that is hard to 
understand. While it is hard to precisely define when a process model is “too large”, 
since understandability is subjective, it has been shown that using more than ap- 
proximately 30 flow objects (i.e. activities, events, gateways) leads to an increased 
probability of making mistakes in a process model (e.g. introducing behavioral is- 
sues). Thus, we suggest to use as few elements as possible per each process model 
level, and in particular to decompose a process model if this has more than 30 flow 
objects. 


Reducing the size of a process model, for example by collapsing its sub- 
processes, is one of the most effective ways of improving a process model’s read- 
ability. Other structural aspects that affect the readability include the density of the 
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Fig. 4.3 A process model for disbursing home loans, laid down over three hierarchical levels via 
the use of sub-processes 


process model connections, the number of parallel branches, the longest path from a 
start to an end event, as well as cosmetic aspects such as the layout, the labels style 
(e.g. always use a verb-noun style), the colors palette, the lines thickness, etc. More 
information on establishing process modeling guidelines can be found in Chap. 5. 

We have shown that we can simplify a process model by first identifying the 
content of a sub-process, and then hiding this content by collapsing the sub-process 
activity. Sometimes, we may wish to proceed in the opposite direction, meaning that 
when modeling a process we already identify activities that can be broken down in 
smaller steps, but we intentionally under-specify their content. In other words, we 
do not link the sub-process activity to a process model at a lower level capturing 
its content (like if by pressing the plus button nothing would happen). The reason 
for doing this is to tell the reader that some activities are made up of sub-steps, but 
that disclosing the details of these is not relevant. This could be the case of activity 
“Ship product” in the order fulfillment example, for which modeling the distinction 
between its internal steps for packaging and for shipping is not relevant. 


4.2 Process Reuse 


By default a sub-process is embedded within its parent process model, and as such 
it can only be invoked from within that process model. Often, when modeling a 
business process we may need to reuse parts of other process models of the same 
organization. For example, a loan provider may reuse the sub-process for signing 
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loans contained in the home loan disbursement for other types of loan, such as a 
process for disbursing student loans or motor loans. 

In BPMN, we can define the content of a sub-process outside its parent process, 
by defining the sub-process as a global process model. A global process model is 
a process model that is not embedded within any process model, and as such can 
be invoked by other process models within the same process model collection. To 
indicate that the sub-process being invoked is a global process model, we use the 
collapsed sub-process activity with a thicker border (this activity type is called call 
activity in BPMN). Coming back to the loan disbursement example of Fig. 4.3, we 
can factor out the sub-process for signing loans and define it as a global process 
model, so that it can also be invoked by a process model for disbursing student 
loans (see Fig. 4.4). 


Question Embedded or global sub-process? 


Our default choice should be to define sub-processes as global process models 
so as to maximize their reusability within our process model collection. Supporting 
processes such as payment, invoicing, HR, printing, are good candidates for being 
defined as global process models, since they are typically shared by various business 
processes within an organization. Besides reusability, another advantage of using 
global process models is that any change made to these models will be automati- 
cally propagated to all process models that invoke them. In some cases, however, 
we may want to keep the changes internal to a specific process. For example, an 
invoicing process used for corporate orders settlement would typically be different 
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from the invoicing process for private orders. In this case, we should keep two model 
variants of the invoice sub-process, each embedded within its parent process model: 
corporate and private order settlement. 


Example 4.1 Let us consider the procurement process of a pharmaceutical company. 


A pharmaceutical company has different business units within its manufacturing depart- 
ment, each producing a specific type of medicine. For example, there is a business unit 
looking after inhaled medications, and another one producing vaccines. The various busi- 
ness units make use of a direct procurement process for ordering chemicals, and of an 
indirect procurement process for ordering spare parts for their equipment. 


The direct procurement process depends on the raw materials that are required to 
produce a specific type of medicine. For example, vaccines typically include ad- 
juvants that help improve the vaccine’s effectiveness, which are not contained in 
inhaled medications. Similarly, inhaled medications contain a chemical propellant 
to push the medicine out of the inhaler, which is not required for vaccines. Since 
this procurement process is specific to each business unit, we need to model it as 
an embedded sub-process within the manufacturing process model of each unit. On 
the other hand, the process for ordering spare parts to the equipment for synthesiz- 
ing chemicals can be shared across all units, since all units make use of the same 
equipment. Thus, we will model this process with a global process model. 


Before concluding our discussion on sub-processes, we need to point to some 
syntactical rules for using this element. A sub-process is a regular process model. It 
should start with at least one start event, and complete with at least one end event. 
If there are multiple start events, the sub-process will be triggered by the first such 
an event that occurs. If there are multiple end events, the sub-process will return 
control to its parent process only when each token flowing in this model reaches 
an end event. Moreover, we cannot cross the boundary of a sub-process with a se- 
quence flow. To pass control to a sub-process, or receive control from a sub-process, 
we should always use start and end events. On the other hand, message flows can 
cross the boundaries of a sub-process to indicate messages that emanate from, or are 
directed to, internal activities or events of the sub-process. 


Exercise 4.2 Identify suitable sub-processes in the business process of Exercise 1.7. 
Among these sub-processes, identify those that are specific to this business process 
versus those that can potentially be shared with other business processes of the same 
company. 


4.3 More on Rework and Repetition 


In the previous chapter we described how to model rework and repetition via the 
XOR gateways. Expanded sub-processes offer an alternative way to model parts 
of a process that can be repeated. Let us consider again the process for addressing 
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Fig. 4.5 The process model for addressing ministerial correspondence of Fig. 3.13 simplified 
using a loop activity 


ministerial correspondence of Example 3.7. To make this model simpler, we can 
take the fragment identified by the XOR-join and the XOR-split (which includes 
the repetition block and the loopback branch) and replace it with a sub-process 
containing the activities in the repetition block. To identify that this sub-process 
may be repeated (if the response is not approved), we mark the sub-process activity 
with a loop symbol, as shown in Fig. 4.5. We can use an annotation to specify the 
loop condition, e.g. “until response approved”. 

As for any sub-process, you may decide not to specify the content of a loop 
sub-process. However, if you do so, do not forget to put a decision activity as the 
last activity inside the sub-process, otherwise there is no way to determine when to 
repeat the sub-process. 


Question Loop activity or cycle? 


The loop activity is a shorthand notation for a structured cycle, i.e. a repetition 
block delimited by a single entry point to the cycle, and a single exit point from 
the cycle, like in the example above. Sometimes there might be more than one en- 
try and/or exit point, or the entry/exit point might be inside the repetition block. 
Consider for example the model in Fig. 4.6. Here the repetition block is made up 
of activities “Assess application’, “Notify rejection” and “Receive customer feed- 
back”; the cycle has an entry point and two exit points, of which one inside the 
repetition block. When an unstructured cycle has multiple exit points, like in this 
case, a loop activity cannot be used, unless additional conditions are used to specify 
the situations in which the cycle can be exited, which will render the model more 
complex. 


Exercise 4.3 


1. Identify the entry and exit points that delimit the unstructured cycles in the pro- 
cess models shown in Solution 3.4 and in Exercise 3.9. What are the repetition 
blocks? 
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Fig. 4.6 An example of unstructured cycle 


2. Model the business process of Solution 3.4 using a loop activity. 


4.3.1 Parallel Repetition 


The loop activity allows us to capture sequential repetition, meaning that instances 
of the loop activity are executed one after the other. Sometimes, though, we may 
need to execute multiple instances of the same activity at the same time, like in the 
following example. 


Example 4.2 In a procurement process, a quote is to be obtained from all preferred 
suppliers. After all quotes are received, they are evaluated and the best quote is 
selected. A corresponding purchase order is then placed. 

Let us assume five preferred suppliers exist. Then we can use an AND-split to 
model five tasks in parallel, each to obtain a quote from one supplier, as shown in 
Fig. 4.7. However, there are several problems with this solution. First, the larger the 
number of suppliers, the larger the resulting model will be, since we need to use 
one task per supplier. Second, we need to revise the model every time the number 
of suppliers changes. In fact, it is often the case in reality that an updated list of 
suppliers is kept in an organizational database which is queried before contacting 
the suppliers. 

To obviate these problems, BPMN provides a construct called multi-instance ac- 
tivity. A multi-instance activity indicates an activity (being it a task or a sub-process) 
that is executed multiple times concurrently. Such a construct is useful when the 
same activity needs to be executed for multiple entities or data items, like for ex- 
ample to request quotes from multiple suppliers (as in our example), to check the 
availability of each line item in an order separately, to send and gather question- 
naires for multiple witnesses in the context of an insurance claim, etc. 

A multi-instance activity is depicted as an activity marked with three small ver- 
tical lines at the bottom. Figure 4.8 shows a revised version of the procurement 
process model in Fig. 4.7. Not only is this model smaller, but it can also work with 
a dynamic list of suppliers, which may change on an instance-by-instance basis. 
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Fig. 4.7 Obtaining quotes from five suppliers 


To do so, we added a task to retrieve the list of suppliers, and passed this list to a 
multi-instance task, which contacts the various suppliers. You would have noticed 
that in this example we have also marked the data object Suppliers list with the 
multi-instance symbol. This is used to indicate a collection of similar data objects, 
like a list of order items, or a list of customers. When a collection is used as input 
to a multi-instance activity, the number of items in the collection determines the 
number of activity instances to be created. Alternatively, we can specify the number 
of instances to be created via an annotation on the multi-instance activity (e.g. “15 
suppliers’, or “as per suppliers database’). 

Let us come back to our example. Assume the list of suppliers has become quite 
large over time, say there are 20 suppliers in the database. As per our organizational 
policies, however, five quotes from five different suppliers are enough to make a 
decision. Thus, we do not want to wait for all 20 suppliers to reply back to our 
request for quote. To do so, we can annotate the multi-instance activity with the 
minimum number of instances that need to complete before passing control to the 
outgoing arc (e.g. “complete when five quotes obtained”, as shown in Fig. 4.8). 
When the multi-instance activity is triggered, 20 tokens are generated, each marking 
the progress of one of the 20 instances. Then, as soon as the first five instances 
complete, all the other instances are canceled (the respective tokens are destroyed) 
and one token is sent to the output arc to signal completion. 


Let us take the order fulfillment example in Fig. 4.2, and expand the content of 
the sub-process for acquiring raw materials. To make this model more realistic, we 
can use a multi-instance sub-process in place of the structure delimited by the two 
OR gateways, assuming that the list of suppliers to be contacted will be determined 
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Fig. 4.9 Using a multi-instance pool to represent multiple suppliers 


on the fly from a suppliers database (the updated model is shown in Fig. 4.9). By the 
same principle, we replace the two pools “Supplier 1” and “Supplier 2” with a single 
pool, namely “Supplier”, which we also mark with the multi-instance symbol—a 


multi-instance pool represents a set of resource classes, or resources, having similar 
characteristics. 
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From this figure we note that there are four message flows connected to the sub- 
process “Ship and invoice”, as a result of collapsing the content of this activity. 
The order in which these messages are exchanged is determined by the activities 
inside this sub-process that receive and send them. In other words, when it comes 
to a collapsed sub-process activity, the message semantics for tasks described in 
Sect. 3.4 is not enforced. 


Exercise 4.4 Model the following process fragment. 


After a car accident, a statement is sought from two witnesses out of the five that were 
present, in order to lodge the insurance claim. As soon as the first two statements are re- 
ceived, the claim can be lodged with the insurance company without waiting for the other 
statements. 


4.3.2 Uncontrolled Repetition 


Sometimes we may need to model that one or more activities can be repeated a 
number of times, without a specific order, until a condition is met. For example, let 
us assume that the customer of our order fulfillment process needs to inquire about 
the progress of their order. The customer may do so simply by sending an e-mail to 
the seller. This may be done any time after the customer has submitted the purchase 
order and as often as the customer desires. Similarly, the customer may attempt to 
cancel the order or update their personal details before the order has been fulfilled. 
These activities are uncontrolled, in the sense that they may be repeated multiple 
times with no specific order, or not occur at all, until a condition is met—in our case 
the order being fulfilled. 

To model a set of uncontrolled activities, we can use an ad-hoc sub-process. 
Figure 4.10 shows the example of the customer’s process, where the completion 
condition (“until order is fulfilled’) has been specified via an annotation. The ad- 
hoc sub-process is marked with a tilde symbol at the bottom of the sub-process box. 

A partial order may be established among the activities of an ad-hoc sub-process 
via the sequence flow. However, we cannot represent start and end events in an ad- 
hoc sub-process. 


Exercise 4.5 Model the following process snippet. 


A typical army recruitment process starts by shortlisting all candidates’ applications. Those 
shortlisted are then called to sit the following tests: drug and alcohol, eye, color vision, 
hearing, blood, urine, weight, fingerprinting and doctor examination. The color vision can 
only be done after the eye test, while the doctor examination can only be done after color 
vision, hearing, blood, urine and weight have been tested. Moreover, it may be required 
for some candidates to repeat some of these tests multiple times in order to get a correct 
assessment, e.g. the blood test may need to be repeated if the candidate has taken too much 
sugar in the previous 24 hours. The candidates that pass all tests are asked to sit a mental 
exam and a physical exam, followed by an interview. Only those that also pass these two 
exams and perform well in the interview can be recruited in the army. 
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Fig. 4.10 Using an ad-hoc sub-process to model uncontrolled repetition 


4.4 Handling Events 


As we pointed out in Chap. 3, events are used to model something that happens in- 
stantaneously in a process. We saw start events, which signal how process instances 
start (tokens are created), and end events, which signal when process instances com- 
plete (tokens are destroyed). When an event occurs during a process, for example 
an order confirmation is received after sending an order out to the customer and 
before proceeding with the shipment, the event is called intermediate. A token re- 
mains trapped in the incoming sequence flow of an intermediate event until the 
event occurs. Then the token traverses the event instantaneously, i.e. events can- 
not retain tokens. An intermediate event is represented as a circle with a double 
border. 


4.4.1 Message Events 


In the previous chapter, we showed that we can mark a start event with an empty en- 
velope to specify that new process instances are triggered by the receipt of a message 
(cf. Fig. 3.16). Besides the start message event, we can also mark an end event and 
an intermediate event with an envelope to capture the interaction between our pro- 
cess and another party. These types of event are collectively called message events. 
An end message event signals that a process concludes upon sending a message. 
An intermediate message event signals the receipt of a message, or that a message 
has just been sent, during the execution of the process. Intermediate and end mes- 
sage events represent an alternative notation to those activities that are solely used 
to send or receive a message. Take for example activities “Return application to ap- 
plicant” and “Receive updated applications” in Fig. 4.1 1a, which is an extract of the 
loan assessment model of Solution 3.7. It is more meaningful to replace the former 
activity with an intermediate send message event and the latter activity with an in- 
termediate receive message event, as illustrated in Fig. 4.11b, since these activities 
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do not really represent units of work, but rather the mechanical sending or receiving 
of a message. An intermediate message event that receives a message is depicted as 
a start message event but with a double border. If the intermediate event signals a 
message being sent, the envelope is darkened. 

Further, if the send activity is immediately followed by an untyped end event, 
we can replace this with an end message event, since again, this activity is merely 
used to send a message after which the process concludes. An end message event 
is depicted as an end event marked with a darkened envelope. Beware that a start 
message event is not an alternative notation for an untyped start event followed 
by a receive activity: these two constructs are not interchangeable. In the former 
case, process instances start upon the receipt of a specific message; in the latter 
case, process instances may start at any time, after which the first activity requires a 
message to be performed. 


Question Typed or untyped event? 


We suggest to specify the type of an event whenever this is known, since it will 
help the reader better understand the process model. 


Exercise 4.6 Is there any other activity in the loan assessment model of Solution 3.7 
that can be replaced by a message event? 


In BPMN, events come in two flavors based on the filling of their marker. 
A marker with no fill, like that on the start message event, denotes a catching event, 
i.e. an event that catches a trigger, typically originating from outside the process. 
A marker with a dark fill like that on the end message event denotes a throwing 
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Fig. 4.12 Using timer events to drive the various activities of a business process 


event, i.e. an event that throws a trigger from within the process. An intermediate 
message event has both flavors since it can be used both as a catching event (the 
message is received from another pool) or as a throwing event (the message is sent 
to another pool). 


4.4.2 Temporal Events 


Besides the message event, there are other triggers that can be specified for a start 
event. One worth of notice is the timer event. This event type indicates that process 
instances start upon the occurrence of a specific temporal event, e.g. every Friday 
morning, every working day of the month, every morning at 7am. 

A timer event may also be used as intermediate event, to model a temporal inter- 
val that needs to elapse before the process instance can proceed. To indicate a timer 
event, we mark the event symbol with a light watch inside the circle. Timer events 
are catching events only since a timer is a trigger outside the control of the process. 
In other words, the process does not generate the timer, but rather reacts to this. 


Example 4.3 Let us consider the following process at a small claims tribunal. 


In a small claims tribunal, callovers occur once a month, to set down the matter for the 
upcoming trials. The process for setting up a callover starts three weeks prior to the callover 
day, with the preparation of the callover list containing information such as contact details of 
the involved parties and estimated hearing date. One week prior to the callover, the involved 
parties are contacted to determine if they are all ready to go to trial. If this is the case, the 
callover is set, otherwise it is deferred to the next available slot. Finally, on the callover day, 
the callover material is prepared and the callover is held. 


This process is driven by three temporal events: it starts three weeks prior to 
the callover date, continues one week prior to the callover date, and concludes on 
the day of the callover. To model these temporal events we need one start and 
two intermediate timer events, as shown in Fig. 4.12. Let us see how this pro- 
cess works from a token semantics point of view. A token capturing a new in- 
stance is generated every time it is three weeks prior to the callover date (we 
assume this date has been scheduled by another process). Once the first activity 
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“Prepare callover list” has been completed, the token is sent through the incom- 
ing arc of the following intermediate timer event, namely “1! week prior to callover 
day’. The event thus becomes enabled. The token remains trapped in the incom- 
ing arc of this event until the temporal event itself occurs, i.e. only when it is one 
week prior to the callover day. Once this is the case, the token instantaneously tra- 
verses the event symbol and moves to the outgoing arc. This is why events are 
said to be instantaneous, since they cannot retain tokens as opposed to activities, 
which retain tokens for the duration of their execution (recall that activities con- 
sume time). 


Exercise 4.7 Model the billing process of an Internet Service Provider (ISP). 


The ISP sends an invoice by email to the customer on the first working day of each month 
(Day 1). On Day 7, the customer has the full outstanding amount automatically debited 
from their bank account. If an automatic transaction fails for any reason, the customer 
is notified on Day 8. On Day 9, the transaction that failed on Day 7 is re-attempted. If 
it fails again, on Day 10 a late fee is charged to the customer’s bank account. At this 
stage, the automatic payment is no longer attempted. On Day 14, the Internet service is 
suspended until payment is received. If on Day 30 the payment is still outstanding, the 
account is closed and a disconnection fee is applied. A debt-recovery procedure is then 
started. 


4.4.3 Racing Events 


A typical scenario encountered when modeling processes with events is the one 
where two external events race against one another. The first of the two events that 
occurs determines the continuation of the process. For example, after an insurance 
quote has been sent to a client, the client may reply either with an acceptance mes- 
sage, in which case an insurance contract will be made, or with a rejection, in which 
case the quote will be discarded. 

This race between external events is captured by means of the event-based exclu- 
sive (XOR) split. An event-based exclusive split is represented by a gateway marked 
by an empty pentagon enclosed in a double-line circle. Figure 4.13 features an event- 
based exclusive split. When the execution of the process arrives at this point (in 
other words—when a token arrives at this gateway), the execution stops until ei- 
ther the message event or the timer event occurs. Whichever event occurs first will 
determine which way the execution will proceed. If the timer event occurs first, a 
shipment status inquiry will be initiated and the execution flow will come back to 
the event-based exclusive gateway. If the message signaling the freight delivery is 
received first, the execution flow will proceed along the sequence flow that leads to 
the AND-join. 

The difference between the XOR-split that we saw in Chap. 3 and the event-based 
XOR-split is that the former models an internal choice that is determined by the out- 
come of a decision activity, whereas the latter models a choice that is determined 
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Fig. 4.13 A race condition between an incoming message and a timer 


by the process environment.! An internal choice is determined by the outcome of a 
decision activity. Thus, the event-based XOR-split can only be followed by interme- 
diate catching events like a timer or a message event, or by receiving activities. Since 
the choice is delayed until an event happens, the event-based split is also known as 
deferred choice. There is no event-based XOR-join, so the branches emanating from 
an event-based split are merged with a normal XOR-join. 


Exercise 4.8 Model the following process. 


A restaurant chain submits a purchase order (PO) to replenish its warehouses every Thurs- 
day. The restaurant chain’s procurement system expects to receive either a “PO Response” 
or an error message. However, it may also happen that no response is received at all due to 
system errors or due to delays in handling the PO on the supplier’s side. If no response is 
received by Friday afternoon or if an error message is received, a purchasing officer at the 
restaurant chain’s headquarters should be notified. Otherwise, the PO Response is processed 
normally. 


The event-based split can be used as the counterpart of an internal decision on 
a collaborating party. For example, a choice made from within the Client pool to 
send either an acceptance message or a rejection message to an Insurer, needs to be 
matched by an event-driven decision on the insurer pool to react to the choice made 
by the client. This example is illustrated in Fig. 4.14. 

Event-based gateways can be used to avoid behavioral anomalies in the com- 
munication between pools. Take for example the collaboration diagram between the 
auctioning service and the seller in Fig. 4.15. This collaboration may deadlock if the 
seller is already registered, as this party will wait for the account creation request 
message which in that case will never arrive. To fix this issue, we need to allow the 
seller to receive the creation confirmation message straightaway in case the seller is 
already registered, as shown in Fig. 4.16. 


‘Specifically, the XOR-split of Chap. 3 is called data-based XOR-split since the branch to take is 
based on the evaluation of two or more conditions on data that are produced by a decision activity. 
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Fig. 4.16 Using an event-based gateway to fix the deadlocking collaboration of Fig. 4.15 


When connecting pools with each other via message flows, make sure you check 
the order of these connections so as to avoid deadlocks. Recall, in particular, that 
an internal decision in one party needs to be matched by an event-based decision in 
the other party, and that an activity with an outgoing message flow will send that 
message upon activity completion, whereas an activity with an incoming message 
flow will wait for that message to start. 


Exercise 4.9 Fix the collaboration diagram in Fig. 4.17. 


Acknowledgement This exercise is partly inspired by: Niels Lohmann: “Correcting 
Deadlocking Service Choreographies Using a Simulation-Based Graph Edit Dis- 
tance”. LNCS 5240, Springer, 2008. 


4.5 Handling Exceptions 


Exceptions are events that deviate a process from its normal course, i.e. from what 
is commonly known as the “sunny-day” scenario. These “rainy-day” situations hap- 
pen frequently in reality, and as such they should be modeled when the objective is 
to identify all possible causes of problems in a given process. Exceptions include 
business faults like an exception due to an out-of-stock or discontinued product, 
and technology faults like a database crash, a network outage or a program logic 
violation. They deviate the normal process course since they cause the interruption 
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Fig. 4.17 A collaboration diagram between a client, a travel agency and an airline 


or abortion of the running process. For example, in case of an out-of-stock prod- 
uct, an order-to-cash process may need to be interrupted to order the product from 
a supplier, or aborted altogether if the product cannot be supplied within a given 
timeframe. 


4.5.1 Process Abortion 


The simplest way of handling an exception is to abort the running process and signal 
an improper process termination. This can be done by using an end terminate event, 
as shown in Fig. 4.18. An end terminate event (depicted as an end event marked 
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Fig. 4.18 Using a terminate event to signal improper process termination 


with a full circle inside), causes the immediate cessation of the process instance at 
its current level and for any sub-process. 

In the example of Fig. 4.18—a variant of the home loan that we already saw in 
Fig. 4.3—a home loan is rejected and the process is aborted if the applicant has 
debts and/or low liability. From a token semantics, the terminate event destroys all 
tokens in the process model and in any sub-process. In our example, this is needed 
to avoid the process to deadlock at the AND-join, since a token may remain trapped 
before the AND-join if there is high liability and debts or low liability and no debts. 

Observe that if a terminate event is triggered from within a sub-process, it will 
not cause the abortion of the parent process but only that of the sub-process, i.e. the 
terminate event is only propagated downwards in a process hierarchy. 


Exercise 4.10 Revise the examples presented so far in this chapter, by using the 
terminate event appropriately. 


4.5.2 Internal Exceptions 


Instead of aborting the whole process, we can handle an exception by interrupting 
the specific activity that has caused the exception. Next, we can start a recovery 
procedure to bring the process back to a consistent state and continue its execution, 
and if this is not possible, only then, abort the process altogether. BPMN provides 
the error event to capture these types of scenario. An end error event is used to 
interrupt the enclosing sub-process and throw an exception. This exception is then 
caught by an intermediate catching error event which is attached to the boundary of 
the same sub-process. In turn, this boundary event triggers the recovery procedure 
through an outgoing branch which is called exception flow. 
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Fig. 4.19 Error events model internal exceptions 


The error event is depicted as an event with a lightning marker. Following the 
BPMN conventions for throwing and catching events, the lightning is empty for the 
catching intermediate event and full for the end throwing event. 

An example of error events is shown in Fig. 4.19 in the context of our order ful- 
fillment process. If there is an out of stock exception, the acquisition of raw materi- 
als is interrupted and the recovery procedure is triggered, which in this case simply 
consists of a task to notify the customer before aborting the process. In terms of 
token semantics, upon throwing an end error event, all tokens are removed from 
the enclosing sub-process (causing its interruption), and one token is sent through 
the exception flow emanating from the boundary error event. There is no restriction 
on the modeling elements we can put in the exception flow to model the recovery 
procedure. Typically, we would complete the exception flow with an end terminate 
event to abort the process, or wire this flow back to the normal sequence flow if the 
exception has been properly handled. 


4.5.3 External Exceptions 


An exception may also be caused by an external event occurring during an activity. 
For example, while checking the stock availability for the product in a purchase 
order, the Seller may receive an order cancellation from the customer. Upon this 
request, the Seller should interrupt the stock availability check and handle the order 
cancellation. Scenarios like the above are called unsolicited exceptions since they 
originate externally to the process. They can be captured by attaching a catching 
intermediate message event to an activity’s boundary, as shown in Fig. 4.20. From 
a token semantics, when the intermediate message event is triggered, the token is 
removed from the enclosing activity, consequently causing the activity interruption, 
and sent through the exception flow emanating from the boundary event, to perform 
the recovery procedure. 
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Before using a boundary event we need to identify the scope within which the 
process should be receptive of this event. For example, in the order fulfillment ex- 
ample, order cancellation requests can only be handled during the execution of task 
“Check stock availability”. Thus, the scope for being receptive to this event is made 
up by this single task. Sometimes the scope should include multiple activities. In 
these cases, we can encapsulate the interested activities into a sub-process and at- 
tach the event to the sub-process’s boundary. 


Exercise 4.11 Model the following routine for logging into an Internet bank ac- 
count. 


The routine for logging into an Internet bank account starts once the credentials entered 
from the user have been retrieved. First, the username is validated. If the username is not 
valid, the routine is interrupted and the invalid username is logged. If the username is valid, 
the number of password trials is set to zero. Then the password is validated. If this is not 
valid, the counter for the number of trials is incremented and if lower than three, the user 
is asked to enter the password again, this time together with a CAPTCHA test to increase 
the security level. If the number of failed attempts reaches three times, the routine is in- 
terrupted and the account is frozen. Moreover, the username and password validation may 
be interrupted should the validation server not be available. Similarly, the server to test the 
CAPTCHA may not be available at the time of log in. In these cases, the procedure is inter- 
rupted after notifying the user to try again later. At any time during the log in routine, the 
customer may close the web-page, resulting in the interruption of the routine. 


4.5.4 Activity Timeouts 


Another type of exception is that provoked by the interruption of an activity which 
is taking too long to complete. To model that an activity must be completed within 
a given timeframe (e.g. an approval must be completed within 24 hours), we can 
attach an intermediate timer event to the boundary of the activity: the timer is acti- 
vated when the enclosing activity starts, and if it fires before the activity completes, 
provokes the activity’s interruption. In other words, a timer event works as a timeout 
when attached to an activity’s boundary. 
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Exercise 4.12 Model the following process fragment. 


Once a wholesale order has been confirmed, the supplier transmits this order to the car- 
rier for the preparation of the transportation quote. In order to prepare the quote, the car- 
rier needs to compute the route plan (including all track points that need to be traversed 
during the travel) and estimate the trailer usage (e.g. whether it is a full track-load, half 
track-load or a single package). By contract, wholesale orders have to be dispatched within 
four days from the receipt of the order. This implies that transportation quotes have to be 
prepared within 48 hours from the receipt of the order to remain within the terms of the 
contract. 


4.5.5 Non-interrupting Events and Complex Exceptions 


There are situations where an external event occurring during an activity should just 
trigger a procedure without interrupting the activity itself. For example, in the order 
fulfillment process, the customer may send a request to update their details during 
the stock availability check. The details should be updated in the customer database 
without interrupting the stock check. In order to denote that the boundary event is 
non-interrupting, we use a dashed double border, as shown in Fig. 4.21. 


Exercise 4.13 Extend the process for assessing loan applications of Solution 3.7 as 
follows. 


An applicant who has decided not to combine their loan with a home insurance plan may 
change their mind any time before the eligibility assessment has been completed. If a request 
for adding an insurance plan is received during this period, the loan provider will simply 
update the loan application with this request. 


Non-interrupting events can be used to model more complex exception handling 
scenarios. Consider again the example in Fig. 4.19 and assume that the customer 
sends a request to cancel the order during the acquisition of raw materials. We catch 
this request with a non-interrupting boundary message event, and first determine 
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Fig. 4.22 Non-interrupting events can be used in combination with signal events to model com- 


plex exception handling scenarios 


the penalty that the customer will need to incur based on the raw materials that 
have already been ordered. We forward this information to the customer who then 


may decide within 48 hours to either 


stop the cancellation, in which case nothing 


is done, or go on with it (see Fig. 4.22). In the latter case, we throw an end signal 
event. This event, depicted with a triangle marker, broadcasts a signal defined by 
the event’s label, which can be caught by all catching signal events bearing the 
same label. In our case, we throw an “Order canceled” signal and catch this with a 


matching intermediate signal event on 
raw materials. This event causes the 


the boundary of the sub-process for acquiring 
enclosing sub-process to be interrupted and 


then triggers a recovery procedure to charge the customer, after which the process is 
aborted. We observe that in this scenario the activity interruption is triggered from 
within the process, but outside the activity itself. 

Observe that the signal event is different from the message event, since it has 
a source but no specific target, whilst a message has both a specific source and a 
specific target. Like messages, signals may also originate from a process modeled 


in a separate diagram. 
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Fig. 4.23 Event sub-processes can be used in place of boundary events, and to catch events thrown 
from outside the scope of a particular sub-process 


4.5.6 Interlude: Event Sub-processes 


An alternative notation to boundary events is the event sub-process. An event sub- 
process is started by the event which would otherwise be attached to the boundary 
of an activity, and encloses the procedure that would be triggered by the boundary 
event. An important difference with boundary events is that event sub-processes do 
not need to refer to a specific activity, but can model events that occur during the 
execution of the whole process. For example, any time during the order fulfillment 
process the customer may send an inquiry about the order status. To handle this 
request, which is not specific to a particular activity of this process, we can use an 
event sub-process as shown in Fig. 4.23. 

The event sub-process is depicted within a dotted rectangle with rounded corners 
which is placed into an expanded sub-process or into the top-level process. Similar 
to boundary events, an event sub-process may or may not interrupt the enclosing 
process depending on whether its start event is interrupting or not. If its start event 
is non-interrupting, this is depicted with a dashed (single) border. 

All syntactical rules for a sub-process apply to the event sub-process, except for 
boundary events, which cannot be defined on event sub-processes. For example, the 
event sub-process can also be represented as a collapsed sub-process. In this case, 
the start event is depicted on the top-left corner of the collapsed event sub-process 
rectangle to indicate how this event sub-process is triggered. 


Question Event sub-processes or boundary events? 


Event sub-processes are self-contained, meaning that they must conclude with 
an end event. This has the disadvantage that the procedure captured inside an event 
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sub-process cannot be wired back to the rest of the sequence flow. The advantage 
is that an event sub-process can also be defined as a global process model, and thus 
be reused in other process models of the same organization. Another advantage is 
that event sub-processes can be defined at the level of an entire process whereas 
boundary events must refer to a specific activity. Thus, we suggest to use event 
sub-processes when the event that needs to be handled may occur during the en- 
tire process, or when we need to capture a reusable procedure. For all other cases, 
boundary events are more appropriate since the procedure triggered by these events 
can be wired back to the rest of the flow. 


Exercise 4.14 Model the following business process for reimbursing expenses. 


After an Expense report is received from an employee, the employee is notified of the 
receipt of the report. Next, a new account must be created if the employee does not already 
have one. The report is then reviewed for automatic approval. Amounts under €1,000 are 
automatically approved while amounts equal to or over €1,000 require manual approval. 
In case of rejection, the employee must receive a Rejection notice by email. In case of 
approval, the reimbursement is deposited directly to the employee’s bank account. At any 
time during the review, the employee can send a Request for amount rectification. In that 
case the rectification is registered and the report needs to be reviewed again. Moreover, if 
the report is not handled within 30 days, the process is stopped and the employee receives 
a Cancelation notice email so that he can re-submit the expense report from scratch. 


4.5.7 Activity Compensation 


As part of a recovery procedure, we may need to undo one or more steps that have 
already been completed, due to an exception that occurred in the enclosing sub- 
process. In fact, the results of these steps, and possibly their side effects, may no 
longer be desired and for this reason they should be reversed. This operation is 
called compensation and tries to restore the process to a business state close to the 
one before starting the sub-process that was interrupted. 

Let us delve into the sub-process for shipment and invoice handling of the order 
fulfillment example and assume that also this activity can be interrupted upon the 
receipt of an order cancellation request (see Fig. 4.24). After communicating the 
cancellation penalty to the customer, we need to revert the effects of the shipment 
and of the payment. Specifically, if the shipment has already been made, we need to 
handle the product return, whereas if the payment has already been made, we need to 
reimburse the Customer. These compensations can be modeled via a compensation 
handler. A compensation handler is made up of a throwing compensate event (an 
event marked with a rewind symbol), a catching intermediate compensate event and 
a compensation activity. The throwing compensate event is used inside the recovery 
procedure of an exception to start the compensation, and can either be an interme- 
diate or an end event (in the latter case, the recovery procedure concludes with the 
compensation). The catching intermediate compensation event is attached to those 
activities that need to be compensated—in our example “Ship product” and “Re- 
ceive payment”. These boundary events catch the compensation request and trigger 
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Fig. 4.24 Compensating for the shipment and for the payment 


a compensation activity specific to the activity to be compensated. For example the 
compensation activity for “Receive payment” is “Reimburse customer’. The bound- 
ary event is connected to the compensation activity via a dotted arrow with an open 
arrowhead, called compensation association (whose notation is the same as that of 
the data association). This activity is marked with the compensate symbol to indi- 
cate its purpose, and must not have any outgoing flow: in case the compensation 
procedure is complex, this activity can be a sub-process. 

Compensation is only effective if the attached activity has completed. Once all 
activities that could be compensated are compensated, the process resumes from af- 
ter the throwing compensation event, unless this is an end event. If the compensation 
is for the entire process, we can use an event sub-process with a start compensate 
event in place of the boundary event. 

In this section we have seen various ways to handle exceptions in business pro- 
cess, from simple process abortion to complex exception handling. Before adding 
exceptions it is important to understand the sunny-day scenario well. So start by 
modeling that. Then think of all possible situations that can go wrong. For each of 
these exceptions, identify what type of exception handling mechanism needs to be 
used. First, determine the cause of the exception: internal or external. Next, decide 
if aborting the process is enough, or if a recovery procedure needs to be triggered. 
Finally, evaluate whether the interrupted activity needs to be compensated as part of 
the recovery procedure. 


124 4 Advanced Process Modeling 


Fig. 4.25 A replenishment [for all 
order is triggered every time ra ees. in 
the stock levels drop below a a 
threshold 


Replenish 
stock 


Stock 
replenished 


Stock levels 


Il 
below threshold ea 


Product 
discontinued 


Remove 
product 
from catalog 


Product 
removed 
due to 
discontinuation 


Exercise 4.15 Modify the model that you created in Exercise 4.14 as follows. 


If the report is not handled within 30 days, the process is stopped, the employee receives a 
cancellation notice email and must re-submit the expense report. However, if the reimburse- 
ment for the employee’s expenses had already been made, a money recall needs to be made, 
to get the money back from the employee, before sending the cancellation notice email. 


4.6 Processes and Business Rules 


A business rule implements an organizational policy or practice. For example, in 
an online shop, platinum customers have a 20 % discount for each purchase above 
€250. Business rules can appear in different forms in a process model. We have 
seen them modeled in a decision activity and in the condition of a flow coming out 
of an (X)OR-split (see Exercise 3.5 for some examples). A third option is to use 
a dedicated BPMN event called conditional event. A conditional event causes the 
activation of its outgoing flow when the respective business rule is fulfilled. Condi- 
tional events, identified by a lined page marker, can be used as start or intermediate 
catching events, including after an event-based gateway or attached to an activity’s 
boundary. An example of conditional event is shown in Fig. 4.25. 

The difference between an intermediate conditional event and a condition on a 
flow is that the latter is only tested once, and if it is not satisfied the corresponding 
flow is not taken (another flow or the default flow will be taken instead). The condi- 
tional event, on the other hand, is tested until the associated rule is satisfied. In other 
words, the token remains trapped before the event until the rule is satisfied. 

In the example of Fig. 4.25, observe the use of the error event on the boundary of 
a multi-instance activity. This event only interrupts the activity instance that refers 
to the particular product being discontinued, i.e. the instance from which the error 
event is thrown. All other interrupting boundary events, i.e. message, timer, signal 
and conditional, interrupt all instances of a multi-instance activity. 


Exercise 4.16 Model the following business process snippet. 


4.7 Process Choreographies 125 


In a stock exchange, stock price variations are continuously monitored during the day. A day 
starts when the opening bell rings and concludes when the closing bell rings. Between the 
two bells, every time the stock price changes by more than 10 %, the entity of the change is 
first determined. Next, if the change is high, a “high stock price” alert is sent, otherwise a 
“low stock price” alert is sent. 


4.7 Process Choreographies 


Sometimes it might be hard to frame a business collaboration between two or more 
parties, e.g. two organizations, by working directly at the level of the collaboration 
diagram. First, the collaboration diagram is typically too low-level and if the terms 
of the interactions between the two parties are not clear yet, it might be confusing to 
mix communication aspects with internal activities. Second, a party may not be will- 
ing to expose their internal activities to other parties (e.g. the logic behind a claim 
approval should remain private). Thus, it might be opportune to first focus on the 
interactions that have to occur among all involved parties, and on the order in which 
these interactions can take place. In BPMN, this information is captured by a chore- 
ography diagram. A choreography diagram is the process model of the interactions 
occurring between two or more parties. This high-level view on a collaboration acts 
as a contract among all involved parties. Once this contract has been crafted, each 
party can take it and refine it into their private processes, or alternatively, all parties 
can work together to refine the choreography into a collaboration diagram. 

Figure 4.26 shows the choreography for the order fulfillment collaboration of 
Fig. 4.9. As we can see, a choreography is indeed a process model: it is started by 
one or more start events and concluded by one or more end events, activities are con- 
nected via sequence flows and gateways are used for branching and merging. The 
key characteristic is, however, that an activity represents an interaction between two 
parties, rather than a unit of work. An interaction can be one-way (one message is 
exchanged) or two-way (a message is followed by a return message in the opposite 
direction). Each interaction has an initiator or sender (the party sending the mes- 
sage), and a recipient or receiver (the party receiving the message, who may reply 
with a return message). For example, the first activity of Fig. 4.26, “Submit pur- 
chase order” takes place between the Customer, who sends the purchase order, and 
the Seller, who receives it. 

A choreography activity is depicted as a box with rounded corners where two 
bands, one at the top, the other at the bottom of the box, represent the two parties 
involved in the interaction captured by the activity. A light band is used for the 
initiator whilst a darkened band is used for the recipient. The position of each band 
with respect to the box is left to the modeler, so long as the two bands are on opposite 
sides. An envelope attached to a band via a dashed line represents the message sent 
by that party. This envelop is darkened if it is the return message of a two-way 
interaction. 

A precedence relation between two interactions can only be established if the 
initiator of the second interaction is involved in the preceding interaction (either as 
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Fig. 4.26 The choreography diagram for the collaboration diagram in Fig. 4.9 


a sender or as a receiver), except for the first interaction. In this way the sender of 
the second interaction ‘knows’ when this can take place. On the other hand, if there 
are no order dependencies between two or more interactions, we can link these 
interactions via an AND-split, as shown in Fig. 4.26. Make sure, however, that the 
sender of each interaction following the split is involved in the interaction preceding 
the split. 

An (X)OR-split models the outcomes of a an internal decision that is taken by one 
party. This imposes that the data upon which the decision is taken are made available 
to that party via an interaction prior to the split. In our example, the data required by 
the XOR-split are extrapolated from the purchase order, which is sent to the seller 
in the interaction just before the split. Furthermore, all interactions immediately 
following the split must be initiated by the party who took the decision. In our 
example, these are done by the seller. In fact, it makes no sense that a decision taken 
by one party results in an interaction initiated by another party—the latter would not 
be able to know the results of the decision at that stage. 

The event-based XOR-split is used when the data to make a choice are not ex- 
posed through an interaction before the split. Thus, the parties not involved in the 
decision will only know about this with the receipt of a message. This imposes that 
the interactions following an event-based split must either have the same sender or 
the same receiver. For example, we use an event-based split to model a situation 
where an applicant waits for a confirmation message that may either arrive from 
a broker or directly from the insurer (the decision of which party to interact with 
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Fig. 4.27 The choreography diagram between a seller, a customer and a carrier 


the applicant is taken by the broker together with the insurer). Figure 4.27 shows 
another example: here a seller waits for one of three possible messages from a cus- 
tomer, representing three different types of complaint. The decision is taken by the 
customer and the seller is not aware of this until the specific complain is received. 
The interactions following an event-based split can be constrained by a timer. In this 
example, if the seller does not receive any message after five days, they will trigger 
an interaction to invoice the customer. In this case, all parties in the interactions fol- 
lowing the split must be involved in the interaction preceding the split in order to be 
aware of the timer. 


Exercise 4.17 The choreography below illustrates the interactions that may occur 
among a seller, a customer and a carrier after the freight has been delivered by the 
carrier to the client. Use this diagram as a template to build the corresponding col- 
laboration diagram. Observe the use of the terminate event in this example. In a 
choreography this event can only be used to denote a negative outcome and not to 
forcefully terminate the choreography, since the parties not involved in the interac- 
tion preceding the terminate event would not know that the terminate event has been 
reached. 
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Complex interactions involving more than one business party are modeled via 
a sub-choreography activity. This activity is represented with the plus symbol (as 
a sub-process) and may have multiple bands representing all roles involved. For 
example, the “Handle damage claim” interaction in Fig. 4.27 occurs between the 
seller, the carrier and the customer. The messages involved in a sub-choreography 
are only visible when expanding the content of the sub-choreography where also 
their order becomes apparent. 

Artifacts cannot be explicitly expressed in a choreography via data objects or data 
stores. This is because a choreography does not have a central control mechanism 
to maintain data. 


Exercise 4.18 Model the choreography and collaboration diagrams for the follow- 
ing mortgage application process at BestLoans. 


The mortgage application process starts with the receipt of a mortgage application from a 
client. When an application is sent in by the client to the broker, the broker may either deal 
with the application themselves, if the amount of the mortgage loan is within the mandate 
the broker has been given by BestLoans, or forward the application to BestLoans. If the 
broker deals with the application themselves, this results in either a rejection or an approval 
letter being sent back to the client. If the broker sends an approval letter, then it forwards the 
details of this application to BestLoans so that from there on the client can interact directly 
with BestLoans for the sake of disbursing the loan. In this case, BestLoans registers the 
application and sends an acknowledgment to the client. 

The broker can only handle a given number of clients at a time. If the broker is not able to 
reply within one week, the client must contact BestLoans directly. In this case, a reduction 
on the interest rate is applied should the application be approved. 

If BestLoans deals with the application directly, its mortgage department checks the credit 
of the client with the Bureau of Credit Registration. Moreover, if the loan amount is more 
than 90 % of the total cost of the house being purchased by the client, the mortgage depart- 
ment must request a mortgage insurance offer from the insurance department. After these 
interactions BestLoans either sends an approval letter or a rejection to the broker, which the 
broker then forwards to the client (this interaction may also happen directly between the 
mortgage department and the client if no broker is involved). 

After an approval letter has been submitted to the client, the client may either accept or reject 
the offer by notifying this directly to the mortgage department. If the mortgage department 
receives an acceptance notification, it writes a deed and sends it to an external notary for 
signature. The notary sends a copy of the signed deed to the mortgage department. Next, the 
insurance department starts an insurance contract for the mortgage. Finally, the mortgage 
department submits a disbursement request to the financial department. When this request 
has been handled, the financial department notifies the client directly. 

Any time during the application process, the client may inquire about the status of their 
application with the mortgage department or with the broker, depending on which entity is 
dealing with the client. Moreover, the client may request the cancellation of the application. 
In this case the mortgage department or the broker computes the application processing 
fees, which depend on how far the application process is, and communicates these to the 
client. The client may reply within two days with a cancellation confirmation, in which 
case the process is canceled, or with a cancellation withdrawal, in which case the process 
continues. If the process has to be canceled, BestLoans may need to first recall the loan (if 
the disbursement has been done), then annul the insurance contract (if an insurance contract 
has been drawn) and finally annul the deed (if a deed has been drawn). 
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4.8 Recap 


This chapter provided us with the means to model complex business processes. We 
first learned how to structure complex process models in hierarchical levels via sub- 
process activities. Sub-processes represent activities that can be broken down in a 
number of internal steps, as compared to tasks, which capture single units of work. 
An interesting aspect of sub-processes is that they can be collapsed to hide details. 
We also discussed how to maximize reuse by defining global sub-processes within a 
process model collection, and invoking them via call activities. A global sub-process 
is modeled once and shared by different process models in a repository. 

We then expanded on the topic of rework and repetition. We illustrated how struc- 
tured loops can be modeled using a loop activity. Furthermore, we presented the 
multi-instance activity as a way to model an activity that needs to be executed mul- 
tiple times without knowing the number of occurrences beforehand. Further, we 
saw how the concept of multi-instantiation can be related to data collections and ex- 
tended to pools. We also discussed ad-hoc sub-processes for capturing unstructured 
repetition. 

Next, we expanded on various types of event. We explained the difference be- 
tween catching and throwing events and distinguished between start, end and inter- 
mediate events. We saw how message exchange between pools can be framed by 
message events, and how timer events can be used to model temporal triggers to the 
process or delays during the process. We then showed how to capture racing condi- 
tions between events external to the process, using an event-based split followed by 
intermediate catching events. 

Afterwards, we showed how to handle exceptions. Exceptions are situations that 
deviate the process from its normal course, due to technology or business faults. 
The simplest way to react to an exception is to abort the process via a terminate 
end event. Exceptions can be handled by using a catching intermediate event on the 
boundary of an activity. If the event is caught during the activity’s execution, the 
activity is interrupted and a recovery procedure may be launched. Another type of 
exception is the activity timeout. This occurs when an activity does not complete 
within a given timeframe. A boundary event can also be configured not to interrupt 
the attached activity. In this case the event is called non-interrupting. These events 
are convenient to model procedures that have to be launched in parallel to an activ- 
ity’s execution, when an event occurs. Related to exception handling is the notion of 
activity compensation. Compensation is required to revert the effects of an activity 
that has been completed, if these effects are no longer desired due to an exception 
that has occurred. 

We then saw how business rules can be defined in process models via conditional 
events. A conditional event, available as a start and catching intermediate event, al- 
lows a process instance to start, or progress, only when the corresponding (boolean) 
business rule evaluates to true. 

We concluded this chapter on advanced process modeling by introducing chore- 
ography diagrams. A choreography diagram models the interactions that happen be- 
tween the various business parties partaking in a business process. Each activity in 


130 4 Advanced Process Modeling 


the choreography captures an interaction between a sender and a receiver. To estab- 
lish an order dependency between two interactions, the sender of the second activity 
must be involved in the first one, otherwise this party will not be able to determine 
when to send the message pertaining to the second interaction. We also discussed the 
rules for using gateways in a choreography where a decision is made by a specific 
party based on data or events. Sub-choreographies can be used to model complex 
interactions involving more than two patties, in a similar vein to sub-processes in a 
collaboration. 
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Solution 4.2 Possible sub-processes are “Request purchase”, “Issue purchase or- 
der’, “Receive goods” and “Handle invoice”. Of these, “Handle invoice” could be 
shared with other procure-to-pay processes of the same company, e.g. with that de- 
scribed in Example 1.1 for BuildIT. The first three sub-processes are internal to 
this procure-to-pay process, because they are specific to the enterprise system that 
supports this process. 


Solution 4.3 


1. In Exercise 3.9 the repetition block goes from activity “Record claim” to activity 
“Review claim rejection”. The entry point to the cycle is the input arc of activ- 
ity “Record claim’; the exit points are arcs “claim to be accepted” and “claim 
rejection accepted”, the former being inside the repetition block. 

2. In Solution 3.4 the repetition block is made up of activities “Check application 
form completeness”, “Return application back to applicant” and “Receive up- 
dated application”. The entry point to the cycle is the outgoing arc of the XOR- 
split, while the exit point is the arc “form complete” which is inside the repetition 
block. To model this cycle with a loop activity, we need to repeat activity “Check 
application form completeness” outside the loop activity, as shown below. 
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In this case using a loop activity is still advantageous, since we reduce the size 
of the original model if we collapse the sub-process. 
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Solution 4.6 Activity “Send acceptance pack” can be replaced by an intermediate 
send message event; activities “Notify cancelation” and “Notify approval” can each 
be replaced by an end message event, thus removing the last XOR-join and the un- 
typed end event altogether. Note that activity “Send home insurance quote” cannot 
be replaced by a message event since it subsumes the preparation of the quote. In 
fact, a more appropriate label for this activity would be “Prepare home insurance 
quote”. Similarly, we cannot get rid of activity “Reject application” as this activity 
changes the status of the application before sending the latter out. 
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Solution 4.10 The following end events should be terminate events: Fig. 4.12— 
“callover deferred”, Fig. 4.14—“Quote rejected” in the Client and Insurer pools, 
Fig. 4.18—“Offer rejected” in the Customer pool, “Offer canceled” in the Travel 
Agency pool and “Payment refused” in the Airline pool. 
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Solution 4.11 
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Solution 4.12 
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Solution 4.13 


Assess application 


Updated 
application 
received 


Application 
returned 
to applicant 


Loan [.../ 
application 
tehecked| 


form 
incomplete 


applicant 
not eligible 


Loan 


Reject 
application 


Loan application 
application & Application rejected 
received Check assessed 
application Loan eae Spits 
ree application Assess eligibility tppleation 
: Application Gomp lcieness) Bie = =—2Ff (Fes Fr ee ee [assessed] 
; assessment 


required 
form 
complete 


Loan 
application 
|unchecked] 


report 


N 
Credit 
| Risk 
history assessment 


Check credit 
history 


Assess loan |-...].... 
risk 


Risk rules 
DB 


Loan : 

application : 

{checked} : 
Appraise Property 
property >| appraisal 


Prepare 
acceptance 
applicant pack 
eligible 


Insurance 
request 
received 


Loan 
application 


Add 
insurance 


request to 
loan 
application Loan 
application 
updated 


Observe that in the “Assess application” sub-process, the Loan application can have 
two possible states: “checked” or “unchecked”. In order to use the Loan application 
in any such state as input of activity “Add insurance request to loan application”, we 
do not specify any state for this data object in the above model. 
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Solution 4.15 
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. 
Solution 4.16 
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In this solution we did not use a boundary event to stop the sub-process for moni- 
toring stock price changes since this way, the sub-process would only stop because 
of an exception. Rather, we used the loop condition to allow the sub-process to 
complete normally, i.e. without being interrupted. 
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Fig. 4.29 Collaboration diagram—part 2/2 (Merchandise return handling fragment) 


In Solution 4.17 we used the link event to lay the diagram over two pages, since 
the model was too large to fit in one page. The link event does not have any se- 
mantics: it is purely a notational expedient to break a diagram over multiple pages. 
An intermediate throwing link event (marked with a full arrow) breaks the process 
flow and provides a link to the diagram where the flow continues; an intermediate 
catching link event (marked with an empty arrow) resumes the flow and indicates 
the diagram where this flow is resumed from. 
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Fig. 4.30 Choreography diagram—part 1/2 
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Fig. 4.31 Choreography diagram—part 
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Fig. 4.32 Collaboration diagram—part 1/3 (Loan establishment fragment) 
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Fig. 4.33 Collaboration diagram—part 2/3 (Loan disbursement fragment) 
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Fig. 4.34 Collaboration diagram—part 3/3 (sub-processes) 
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Exercise 4.19 


1. Model the prescription fulfillment process described in Exercise 1.6. Use sub- 


processes where required, and nest them appropriately. 


2. Is there any sub-process that can potentially be shared with other business pro- 
cesses of the same pharmacy, or of other pharmacies? 
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Exercise 4.20 Model the business process described in Exercise 3.12 using a loop 
activity. 


Exercise 4.21 


1. What is the limitation of using a loop activity to model repetition instead of using 
unstructured cycles? 

2. What is the requirement for a sub-process to be used as a loop activity? 

3. Model the procure-to-pay process described in Example 1.1. 


Hint Use the model in Fig. 1.6 as a starting point for item (3). 


Exercise 4.22 Model the following business process. 


Mail from the party is collected on a daily basis by the mail processing unit. Within this 
unit, the mail clerk sorts the unopened mail into the various business areas. The mail is then 
distributed. When the mail is received by the registry, it is opened and sorted into groups for 
distribution, and thus registered in a mail register. Afterwards, the assistant registry manager 
within the registry performs a quality check. If the mail is not compliant, a list of requisi- 
tions explaining the reasons for rejection is compiled and sent back to the party. Otherwise, 
the matter details are captured and provided to the cashier, who takes the applicable fees 
attached to the mail. At this point, the assistant registry manager puts the receipt and copied 
documents into an envelope and posts it to the party. Meantime, the cashier captures the 
party details and prints the physical court file. 


Exercise 4.23 Model the following process for selecting Nobel prize laureates for 
chemistry. 


September: nomination forms are sent out. The Nobel committee sends out confidential 
forms to around 3,000 people—selected professors at universities around the world, No- 
bel laureates in physics and chemistry, and members of the Royal Swedish Academy of 
Sciences, among others. 

February: deadline for submission. The completed nomination forms must reach the No- 
bel Committee no later than 31 January of the following year. The committee screens the 
nominations and selects the preliminary candidates. About 250-350 names are nominated 
as several nominators often submit the same name. 

March—May: consultation with experts. The Nobel committee sends the list of the pre- 
liminary candidates to specially appointed experts for their assessment of the work of the 
candidates. 

June-August: writing of the report. The Nobel committee puts together the report with 
recommendations to be submitted to the Academy. The report is signed by all members of 
the committee. 

September: committee submits recommendations. The Nobel committee submits its report 
with recommendations on the final candidates to the members of the Academy. The report 
is discussed at two meetings of the chemistry section of the Academy. 

October: Nobel laureates are chosen. In early October, the Academy selects the Nobel lau- 
reates in chemistry through a majority vote. The decision is final and without appeal. The 
names of the Nobel laureates are then announced. 

December: Nobel laureates receive their prize. The Nobel prize award ceremony takes place 
on 10 December in Stockholm, where the Nobel laureates receive their Nobel prize, which 
consists of a Nobel medal and diploma, and a document confirming the prize amount. 
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Acknowledgement This exercise is taken from “Nomination and Selection of Chem- 
istry Laureates”, Nobelprize.org. 29 Feb 2012 (http://www.nobelprize.org/nobel_ 
prizes/chemistry/nomination). 


Exercise 4.24 


1. What is the difference between throwing and catching events? 

2. What is the meaning of an event attached to an activity’s boundary and what 
events can be attached to an activity’s boundary? 

3. What is the difference between the untyped end event and the terminate end 
event. 


Exercise 4.25 What is wrong with the following model? 
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Exercise 4.26 Extend the billing process model seen in Exercise 4.7 as follows. 


Any time after the first transaction has failed, the customer may pay the invoice directly to 
the ISP. If so, the billing process is interrupted and the payment is registered. This direct 
payment must also cover the late fees, based on the number of days passed since Day 7 (the 
last day to avoid incurring late fees). If the direct payment does not include late fees, the 
ISP sends a notification to the customer that the fees will be charged in the next invoice, 
before concluding the process. 
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Exercise 4.27 What is wrong with the following model? 
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Exercise 4.28 Model the following business process at a supplier. 


After a supplier notifies a retailer of the approval of a purchase order, the supplier can either 
receive an order confirmation, an order change or an order cancellation from the retailer. It 
may happen that no response is received at all. If no response is received after 48 hours, or if 
an order cancellation is received, the supplier will cancel the order. If an order confirmation 
is received within 48 hours, the supplier will process the order normally. If an order change 
is received within 48 hours, the supplier will update the order and ask again the retailer for 
confirmation. The retailer is allowed to change an order at most three times. Afterwards, the 
supplier will automatically cancel the order. 


Exercise 4.29 Revise the model in Exercise 3.9 by using the terminate event. 


Exercise 4.30 Model the following business process. 


When a claim is received, it is first registered. After registration, the claim is classified 
leading to two possible outcomes: simple or complex. If the claim is simple, the insurance 
policy is checked. For complex claims, both the policy and the damage are checked inde- 
pendently. A possible outcome of the policy check is that the claim is invalid. In this case, 
any processing is canceled and a letter is sent to the customer. In the case of a complex 
claim, this implies that the damage checking is canceled if it has not been completed yet. 
After the check(s), an assessment is performed which may lead to two possible outcomes: 
positive or negative. If the assessment is positive, the garage is phoned to authorize the 
repairs and the payment is scheduled (in this order). In any case (whether the outcome is 
positive or negative), a letter is sent to the customer and the process ends. At any moment 
after the registration and before the end of the process, the customer may call to modify the 
details of the claim. If a modification occurs before the payment is scheduled, the claim is 
classified again (simple or complex) and the process is repeated. If a request to modify the 
claim is received after the payment is scheduled, the request is rejected. 


Exercise 4.31 Model the following business process. 
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An order handling process starts when an order is received. The order is first registered. 
If the current date is not a working day, the process waits until the following working day 
before proceeding. Otherwise, an availability check is performed and a purchase order re- 
sponse is sent back to the customer. If any item is not available, any processing related to 
the order must be stopped. Thereafter, the client needs to be notified that the purchase order 
cannot be further processed. Anytime during the process, the customer may send a purchase 
order cancel request. When such a request is received, the purchase order handling process 
is interrupted and the cancellation is processed. The customer may also send a “Customer 
address change request” during the order handling process. When such a request is received, 
it is just registered, without further action. 


Exercise 4.32 


1. What is the difference between a collaboration and a choreography diagram? 
What are the respective modeling objectives? 

2. Model the choreography diagram for the collaboration diagram that you modeled 
in Exercise 3.7. 


Exercise 4.33 Model the choreography and collaboration diagrams for the follow- 
ing business process for electronic land development applications. 


The Smart Electronic Development Assessment System (Smart eDA) is a Queensland Gov- 
ernment initiative aimed to provide an intuitive service for preparing, lodging and assess- 
ing land development applications. The land development business process starts with the 
receipt of a land development application from an applicant. Upon the receipt of a land 
development application, the assessment manager interacts with the cadastre to retrieve ge- 
ographical information on the designated development area. This information is used to 
get an initial validation of the development proposal from the city council. If the plan is 
valid, the assessment manager sends the applicant a quote of the costs that will incur to 
process the application. These costs depend on the type of development plan (for residential 
or commercial purposes), and on the permit/license that will be required for the plan to be 
approved. If the applicant accepts the quote, the assessment can start. 

The assessment consists of a detailed analysis of the development plan. First, the assessment 
manager interacts with the Department of Main Roads (DMR) to check for conflicts with 
planned road development works. If there are conflicts, the application cannot proceed and 
must be rejected. In this case, the applicant is notified by the assessment manager. The 
applicant may wish to modify the development plan and re-submit it for assessment. In this 
case, the process is resumed from where it was interrupted. 

If the development plan includes modifications to the natural environment, the assessment 
manager needs to request a land alteration permit to the Department of Natural Resources 
and Water (NRW). If the plan is for commercial purposes, additional fees will be applied 
to obtain this permit. Once the permit is granted, this is sent by NRW directly to the ap- 
plicant. Likewise, if the designated development area is regulated by special environment 
protection laws, the assessment manager needs to request an environmental license to the 
Environmental Protection Agency (EPA). Similarly, once the license is granted, this is sent 
by EPA directly to the applicant. Once the required permit and/or license have been ob- 
tained, the assessment manager notifies the Applicant of the final approval. 

At any time during this process, the applicant can track the progress of their application by 
interacting directly with the assessment manager. 

Assessment manager, cadastre, DMR, NRW and EPA are all Queensland Government enti- 
ties. In particular, NRW and EPA are part of the Department of Environment and Resource 
Management within the Queensland Government. 
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Exercise 4.34 Model the choreography and collaboration diagrams for the follow- 
ing business process for ordering maintenance activities at Sparks. 


The ordering business process starts with the receipt of a request for work order from a 
customer. Upon the receipt of this request, the ordering department of Sparks estimates 
the expected usage of supplies, parts and labor and prepares a quote with the estimated 
total cost for the maintenance activity. If the customer’s vehicle is insured, the ordering 
department interacts with the insurance department to retrieve the details of the customer’s 
insurance plan so that these can be attached to the quote. The ordering department then 
sends the quote to the customer, who can either accept or reject the quote by notifying 
the ordering department within five days. If the customer accepts the quote, the ordering 
department contacts the warehouse department to check if the required parts are in stock 
before scheduling an appointment with the customer. If some parts are not in stock, the 
ordering department orders the required parts by interacting with a certified reseller and 
waits for an order confirmation from the reseller, to be received within three days. If it is 
not received, the order department orders the parts again from a second reseller. If no reply 
is received from the second reseller too, the order department notifies the customer that the 
parts are not available and the process terminates. If the required parts are in stock or have 
been ordered, the ordering department interacts with an external garage to book a suitably 
equipped service bay and a suitably qualified mechanic to perform the work. A confirmation 
of the appointment is then sent by the garage to the order department which forwards the 
confirmation to the customer. The customer has one week to pay Sparks, otherwise the 
ordering department cancels the work order by sending a cancellation notice to both the 
service bay and the mechanic that have been booked for this order. If the customer pays in 
time, the work order is performed. 


Exercise 4.35 Model the choreography and collaboration diagrams for the follow- 
ing business process at MetalWorks. Keep in mind that the purpose of this BPMN 
diagram is to serve as a means of communication between the business stakeholders 
and the IT team who has to build a software system to automate this process. 


A build-to-order (BTO) process, also known as make-to-order process, is an “‘order-to-cash” 
process where the products to be sold are manufactured on the basis of a confirmed purchase 
order. In other words, the manufacturer does not maintain any ready-to-ship products in their 
stock. Instead, the products are manufactured on demand when the customer orders them. 
This approach is used in the context of customized products, such as metallurgical products, 
where customers often submit orders for products with very specific requirements. 

We consider a BTO process at a company called MetalWorks. The process starts when 
MetalWorks receives a purchase order (PO) from one of its customers. This PO is called the 
“customer PO”. The customer PO may contain one or multiple line items. Each line item 
refers to a different product. 

Upon receiving a customer PO, a sales officer checks the PO to determine if all the line 
items in the order can be produced within the timeframes indicated in the PO. As a result 
of this check, the sales officer may either confirm the customer PO or ask the customer 
to revise the terms of the PO (for example: change the delivery date to a later date). In 
some extreme cases, the sales officer may reject the PO, but this happens very rarely. If 
the customer is asked to revise the PO, the BTO process will be put in “stand-by” until the 
customer submits a revised PO. The sales officer will then check the revised PO and either 
accept it, reject it, or ask again the customer to make further changes. 

Once a PO is confirmed, the sales officer creates one “work order” for each line item in the 
customer PO. In other words, one customer PO gives place to multiple work orders (one 
per line item). The work order is a document that allows employees at MetalWorks to keep 
track of the manufacturing of a product requested by a customer. 
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In order to manufacture a product, multiple raw materials are typically required. Some of 
these raw materials are maintained in stock in the warehouse of MetalWorks, but others need 
to be sourced from one or multiple suppliers. Accordingly, each work order is examined by a 
production engineer. The production engineer determines which raw materials are required 
in order to fulfill the work order. The production engineer annotates the work order with a 
list of required raw materials. Each raw material listed in the work order is later checked 
by a procurement officer. The procurement officer determines whether the required raw 
material is available in stock, or it has to be ordered. If the material has to be ordered, the 
procurement officer selects a suitable supplier for the raw material and sends a PO to the 
selected supplier. This “PO for a raw material” is called a “material PO”, and it is different 
from the customer PO. A material PO is a PO sent by MetalWorks to one of its suppliers, 
whereas a customer PO is a PO received by MetalWorks from one of its customers. 

Once all materials required to fulfill a work order are available, the production can start. 
The responsibility for the production of a work order is assigned to the same production 
engineer who previously examined the work order. The production engineer is responsible 
for scheduling the production. Once the product has been manufactured, it is checked by a 
quality inspector. Sometimes, the quality inspector finds a defect in the product and reports 
it to the production engineer. The production engineer then decides whether: (i) the product 
should undergo a minor fix; or (11) the product should be discarded and manufactured again. 
Once the production has completed, the product is shipped to the customer. There is no need 
to wait until all the line items requested in a customer PO are ready before shipping them. 
As soon as a product is ready, it can be shipped to the corresponding customer. 

At any point in time (before the shipment of the product), the customer may send a “cancel 
order’ message for a given PO. When this happens, the sales officer determines if the order 
can still be canceled, and if so, whether or not the customer should pay a penalty. If the 
order can be canceled without penalty, all the work related to that order is stopped and the 
customer is notified that the cancellation has been successful. If the customer needs to pay a 
penalty, the sales officer first asks the customer if they accept to pay the cancellation penalty. 
If the customer accepts to pay the cancellation penalty, the order is canceled and all work 
related to the order is stopped. Otherwise, the work related to the order continues. 


4.11 Further Reading 


In this chapter we showed how sub-processes can be used to reduce the complex- 
ity of a process model by reducing the overall process model size. Size is a metric 
strongly related to the understandability of a process model. Intuitively, the smaller 
the size, the more understandable will the model be. There are other metrics that can 
be measured from a process model to assess its understandability, for instance the 
degree of structuredness, the diameter, and the coefficient of connectivity. A com- 
prehensive discussion on process model metrics is available in [50]. The advantages 
of modularizing process models into sub-processes and automatic techniques are 
covered in [75], while the correlation between number of flow objects and error 
probability in process models is studied in [54, 55]. 

BPMN 2.0 provides various other event types besides the main ones presented 
in this chapter. For example, the link event can be used to modularize a process 
sequentially (useful when a process model does not fit on a single paper and has to be 
divided over multiple papers). An example of link event is shown in Figs. 4.28 and 
4.29. The multiple event can be used to catch one of a set of events or throw a set of 
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events. Moreover, BPMN 2.0 provides a further diagram type besides collaborations 
and choreographies. This diagram type is called conversation diagram, and focuses 
on the messages exchanged by two or more process parties, abstracting from the 
precise order in which the messages occur. All these constructs are described in 
detail in the BPMN 2.0 specification by OMG [61]. There are also various books 
that present BPMN 2.0 by example, among others [2, 87, 107]. 

This chapter concludes our coverage of the BPMN 2.0 language. For further in- 
formation on this language, we point to the BPMN web-site: www.bpmn.org, where 
the official specification can be downloaded from. This site also provides a link to a 
handy BPMN poster, a quick reference guide on all BPMN elements and includes 
a comprehensive list of books on the subject, as well as tool implementations that 
support this standard. 


Chapter 5 
Process Discovery 


All truths are easy to understand once they are discovered; 
the point is to discover them. 
Galileo Galilei (1564-1642) 


The previous chapters showed how to create a BPMN model. This chapter goes 
further by showing how to create models that are both correct and complete. To this 
end, one needs to thoroughly understand the operation of a business process, and 
one needs to possess the technical skills to represent it in an appropriate BPMN 
model. These two types of skill are hardly ever unified in the same person. Hence, 
multiple stakeholders with different and complementary skills are typically involved 
in the construction of a process model. 

This chapter presents the challenges faced by the stakeholders involved in the 
lead-up to a process model. Then, we discuss methods to facilitate effective commu- 
nication and information gathering in this setting. Given the information gathered in 
this way, we show step by step how to construct a process and what criteria should 
be verified before a process model is accepted as an authoritative representation of 
a business process. 


5.1 The Setting of Process Discovery 


Process discovery is defined as the act of gathering information about an existing 
process and organizing it in terms of an as-is process model. This definition em- 
phasizes gathering and organizing information. Accordingly, process discovery is 
a much broader activity than modeling a process. Clearly, modeling is a part of 
this activity. The problem is though that modeling can only start once enough in- 
formation has been put together. Indeed, gathering information often proves to be 
cumbersome and time-consuming in practice. Therefore, we need to first define a 
setting in which information can be gathered effectively. In order to address these 
issues, we can describe four phases of process discovery: 


1. Defining the setting: This phase is dedicated to assembling a team in a company 
that will be responsible for working on the process. 
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2. Gathering information: This phase is concerned with building an understanding 
of the process. Different discovery methods can be used to acquire information 
on a process. 

3. Conducting the modeling task: This phase deals with organizing the creation of 
the process model. The modeling method gives guidance for mapping out the 
process in a systematic way. 

4. Assuring process model quality: This phase aims to guarantee that the result- 
ing process models meet different quality criteria. This phase is important for 
establishing trust in the process model. 


Typically, one or several process analysts are responsible for driving the mod- 
eling and analysis of a business process. Often, the process analyst is not familiar 
with all details of the business process. The definition of the setting of process dis- 
covery is critical since it helps the process analyst to secure the commitment of 
various domain experts for providing information on the process. These domain 
experts have to cover the relevant perspectives on the process. Therefore, differ- 
ent domain experts should be involved. A domain expert is any individual who has 
intimate knowledge about how a process or activity is performed. Typically, the do- 
main expert is a process participant, but it can also be a process owner or a manager 
who works closely with the process participants who perform the process. Also 
suppliers and customers of the process can be considered as domain experts. The 
involved domain experts should jointly have insight into all activities of the process. 
It is the task of the process owner to secure the commitment and involvement of 
these persons. In the following, we will focus on the relationship between process 
analyst and domain expert in order to illustrate three challenges of process discov- 
ery. 


5.1.1 Process Analyst Versus Domain Expert 


One fundamental problem of process discovery relates to the question of who is 
going to model the business process. This problem is illustrated by the following 
exercise. 


Exercise 5.1 Consider the following two tasks, and explain their difference: 


e The task of modeling the process of signing a rental contract in your city. 
e The task of modeling the process of getting a license plate for your car in Liecht- 
enstein as a foreign resident. 


The point of this exercise is to emphasize a potential difference in knowledge 
about processes. If you have already acquired some knowledge of mapping pro- 
cesses with BPMN by the help of this book, you will be able to create an initial 
process model for the rental process. The reason is that you not only have modeling 
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Table 5.1 Typical profile of process analyst and domain expert 


Aspect Process Analyst Domain Expert 
Modeling Skills strong limited 
Process Knowledge limited strong 


knowledge but also some knowledge about the domain of renting a flat in your city. 
The case is likely to be different for getting a license plate for a car in Liechtenstein 
as a foreign resident. There are only few foreign residents living in Liechtenstein, 
our colleague Jan vom Brocke being one of them. Most other people would not 
know how this process works. If we are supposed to model a process that we do 
not know, we have to gather an extensive amount of information about it in order 
to understand how it works. That is exactly the situation we are typically facing in 
practice: a process needs to be modeled, we have the required modeling skills, but 
we have only limited knowledge of the corresponding domain. 

In order to describe the typical modeling situation in a plastic way, we distin- 
guish between the role of a process analyst and the role of a domain expert. In a real 
modeling project, we have one or a few process analysts and several domain experts. 
Process analysts and domain experts have complementary roles in the act of process 
discovery as well as different strengths as shown in Table 5.1. The process analyst 
is the one who has profound knowledge of business process modeling techniques. 
A process analyst is familiar with languages like BPMN and skilled in organizing 
information in terms of a process diagram. However, process analysts have typically 
a limited understanding of the concrete process that is supposed to be modeled. For 
this reason, they depend upon the information being provided by domain experts. 
Domain experts have detailed knowledge of the operation of the considered business 
process. They have a clear understanding of what happens within the boundaries of 
the process, which participants are involved, which input is required, and which 
output is generated. On the downside, the domain expert is typically not familiar 
with languages like BPMN. In some companies, domain experts even refuse to dis- 
cuss process models and diagrams, because they feel more comfortable by sticking 
to natural language for explaining what is happening in the process. As a conse- 
quence, domain experts often rely on a process analyst for organizing their process 
knowledge in terms of a process model. 

At this stage, it has to be emphasized that the difference in modeling skills of 
process analysts and domain experts only results from different exposure to prac- 
tical modeling and modeling training. Many companies use training programs for 
improving the modeling skills of domain experts. Such training is a prerequisite for 
modeling initiatives where process participants are expected to model processes on 
their own. On the other hand, there are consulting companies that specialize in a 
particular domain. It is an advantage when process analysts of consultancies can 
be assigned to modeling projects who are experts in modeling and have at least a 
certain level of domain expertise. 
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5.1.2 Three Process Discovery Challenges 


The fact that modeling knowledge and domain knowledge is often available in dif- 
ferent persons in a modeling project has strong implications. It gives rise to three 
essential challenges of process discovery, namely fragmented process knowledge, 
thinking in cases, and lack of familiarity with process modeling languages. 


Exercise 5.2. An online book retailer faces a problem with its order process in terms 
of processing time. In order to identify the root cause of the problem, the company 
decides that every team involved with the order process should model its part of the 
process. Why could this approach be problematic? 


The first challenge of process discovery relates to fragmented process knowl- 
edge. Business processes define a set of logically related activities. These activities 
are typically assigned to specialized participants. This has the consequence that a 
process analyst needs to gather information about a process not only by talking with 
a single domain expert, but with several domain experts who are responsible for 
the different tasks of the process. Typically, domain experts have an abstract under- 
standing of the overall process and a very detailed understanding of their own task. 
This makes it often difficult to puzzle the different views together. In particular, one 
domain expert might have a different idea about which output has to be expected 
from an upstream activity than the domain expert actually working on it. Potential 
conflicts in the provided information have to be resolved. It is also often the case that 
the rules of the process are not explicitly defined in detail. In those situations, do- 
main experts may operate with diverging assumptions, which are often not exactly 
consistent. Fragmented process knowledge is one of the reasons why process dis- 
covery requires several iterations. Having received input from all relevant domain 
experts, the process analyst has to make proposals for resolving inconsistencies, 
which again requires feedback and eventually approval of the domain experts. 

The second challenge of process discovery stems from the fact that domain ex- 
perts typically think of processes on a case level. Domain experts will find it easy 
to describe the activities they conducted for one specific case, but they might have 
problems responding to general questions about how a process works in the general 
way. Process analysts often get answers like “you cannot really generalize, every 
case is different” to such a question. It is indeed the task of the process analyst to 
organize and abstract from the pieces of information provided by the domain expert 
in such a way that a systematically defined process model can emerge. Therefore, it 
is required to ask specific questions about what happens if some task is completed, 
what if certain conditions do or do not hold, and what if certain deadlines are not 
met. In this way, the process analyst can reverse engineer the conditions that govern 
the routing decisions of a business process. 

The third challenge of process discovery is a result of the fact that domain experts 
are typically not familiar with business process modeling languages. This observa- 
tion already gave rise to the distinction of domain experts and process analysts. In 
this context, the problem is not only that domain experts are often not trained to 


5.1 The Setting of Process Discovery 159 


create process models themselves, but also that they are not trained to read pro- 
cess models that others have created. This lack of training can encumber the act of 
seeking feedback to a draft of a process model. In this situation it is typically not 
appropriate to show the model to the domain expert and ask for corrections. Even 
if domain experts understand the activity labels well, they would often not under- 
stand the sophisticated parts of control flow captured in the model. Therefore, the 
process analyst has to explain the content of the process model in detail, for exam- 
ple by translating the formal notation of the process model to a natural-language 
description with the same meaning. Domain experts will feel at ease in responding 
to these natural-language explanations, pointing out aspects that need modification 
or further clarification according to their understanding of the process. 


5.1.3 Profile of a Process Analyst 


The skills of a process analyst play an important role in process discovery. Expert 
process analysts can be described based on a set of general dispositions, their actual 
behavior in a process analysis project, and in terms of the process resulting from 
their efforts. 


Exercise 5.3 You are the manager of a consulting company, and you need to hire 
a person for the newly signed process analysis project with an online book retailer. 
Consider the following two profiles, who would you hire as a process analyst? 


e Mike Miller has ten years of work experience with an online retailer. He has 
worked in different teams involved with the order process of the online retailer. 

e Sara Smith has five years of experience working as a process analyst in the bank- 
ing sector. She is familiar with two different process modeling tools. 


Research on expertise in the general area of system analysis and design has found 
that there are certain personal traits that are likely to be observed for expert process 
analysts. Apparently, there seems to exist a set of certain personal dispositions that 
help in becoming an expert in process analysis. One of the ways to describe per- 
sonality is the so-called Five Factor Model developed in psychological research. 
In essence, this model contains the dimensions openness (appreciating art, emo- 
tion, and adventure), conscientiousness (tendency to self-discipline, achievement 
and planning), extraversion (being positive, energetic, and seeking company), agree- 
ableness (being compassionate and cooperative), and neuroticism (being anxious, 
depressed and vulnerable). These factors have also been studied regarding their 
connection with expert analysts. These experts appear to be strong both in terms 
of conscientiousness and extraversion. Indeed, process discovery projects require a 
conscientious planning and coordination of interviews with various domain experts 
in a limited period of time. Furthermore, process discovery projects are sometimes 
subject to enterprise-internal politics in situations where the agenda of different pro- 
cess stakeholders is not thoroughly clear or where stakeholders might fear losing 
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their position. In such an environment, it is valuable to have an energetic and ex- 
traverted process analyst involved who is able to create a positive atmosphere for 
working on the project. 

Process discovery in general belongs to the category of ill-defined problems. This 
means in the beginning of a process discovery project, it is not exactly clear who 
of the domain experts have to be contacted, which documentation can be utilized, 
and which agenda the different stakeholders might have in mind. The way how 
expert analysts navigate through a project is strongly influenced by experiences with 
former projects. Therefore, there is a strong difference between the way how novices 
and expert analysts conduct problem understanding and problem solving. In terms of 
problem understanding, it has been observed that expert analysts approach a project 
in terms of what are the things that need to be achieved. Novices lack this clear goal 
orientation, and try to approach things in a bottom-up way. This means, they often 
start by investigating material that is easily accessible and talk to persons that readily 
respond. Experts work in a different way. They have an explicit set of triggers and 
heuristics available from experiences with prior projects. They tend to pay specific 
attention to the following aspects: 


e Getting the right people on board. If you need to talk to a given process partici- 
pant, make sure their immediate supervisor and the one above them is on board 
and that the process participant knows that their hierarchy backs their involve- 
ment in the process discovery effort. 

e Having a set of working hypotheses on how the process is structured at different 
levels of details. In order to progress with the project, it is important to have a 
short and precise set of working hypotheses, which they step-by-step challenge. 
Prepare a extensive set of questions and assumptions to be discussed in workshops 
or interviews. 

e Identifying patterns in the information provided by domain experts. These can 
be utilized for constructing parts of a process model. Such pieces of information 
typically refer to specific control structure. For instance, statements about certain 
activities being alternative, exclusive, or subject to certain conditions often point 
to the usage of XOR-gateways. In a similar way, statements about activities being 
independent of another, or sometimes being in one or another order, often sug- 
gest concurrency. For their knowledge of such patterns, it is often easy for expert 
analysts to sketch out processes. 

e Paying attention to model aesthetics. Models have to look nice to be engaging 
to a wide audience. This does not only help to have a resulting model that is 
easy to understand by stakeholders, but also valuable throughout the process of 
creating the model. Experts also use the right level of abstraction. For example, 
you should not show a super-detailed model to an executive-level manager. The 
importance of layout is apparent from the fact that expert analysts often take half 
of the time while creating a model for repositioning its elements in a meaningful 
way. 
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As we have now a rough idea of the tasks that a process analyst has and which 
capabilities and limitations he has to keep in mind when interacting with domain 
experts, we turn to different techniques for gathering information about a process. 
In general, we distinguish three classes of discovery techniques, namely evidence- 
based discovery, interview-based discovery, and workshop-based discovery. There 
are strengths and limitations, which we will discuss subsequently. 


Exercise 5.4 Imagine you would be assigned the task of modeling the process of 
how a book order is processed by your favorite online book retailer. How can you 
systematically gather the required pieces of information about this process? 


5.2.1 Evidence-Based Discovery 


Various pieces of evidence are typically available for studying how an existing pro- 
cess works. Here, we discuss three methods: document analysis, observation, and 
automatic process discovery. 

Document analysis exploits the fact that there is usually documentation material 
available that can be related to an existing process. However, there are some poten- 
tial issues with document analysis. First, most of the documentation that is available 
about the operations of a company is not readily organized in a process-oriented 
way. Think of an organization chart, for instance. It defines the departments and po- 
sitions, it is helpful to identify a potential set of process stakeholders. Such material 
can help to structure phases of a process. For example, in case of our online book 
retailer, it might reveal that the sales department, the logistics department and the 
finance department are likely to be involved with the book order. Second, the level 
of granularity of the material might not be appropriate. While an organization chart 
draws rather an abstract picture of a company, there are often many documents that 
summarize parts of a process on a too fine-granular level. Many companies docu- 
ment detailed work instructions for tasks and work profiles for positions. These are 
typically too detailed for modeling processes. Third, many of the documents are 
only partially trustworthy. For a process discovery project, it is important to identify 
how a process works in reality. Many documents do not necessarily show reality. 
Some of them are outdated and some state how things should work idealistically, 
and not how people conduct them in reality. The advantage of document analysis 
is that a process analyst can use them to get familiar with certain parts of a process 
and its environment, and also to formulate hypotheses. This is helpful before talk- 
ing to domain experts. On the downside, a process analyst has to keep in mind that 
documents do not necessarily reflect the reality of the process. 

If we use observation as a method of discovery, we directly follow the process- 
ing of individual cases in order to get an understanding of how a process works. 
The process analyst can either play the active role of a customer of a process or the 
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passive role of an observer. As part of the active customer role, the process analyst 
triggers the execution of a process and records the steps that are executed and the set 
of choices that are offered. For instance, in the case of the online book retailer, the 
analyst can create a new book order and keep track of which activities are performed 
at the side of the retailer. This provides a good understanding of the boundaries of 
the process and its essential milestones. However, the analyst will only see those 
parts of the process that require interaction with the customer. All backoffice pro- 
cessing remains a black box. The role of a passive observer is more appropriate for 
understanding the entire process, but it also requires access to the people and sights 
where the process is being worked on. Usually, such access requires the approval of 
the managers and supervisors of the corresponding teams. Furthermore, there might 
be a potential issue with people acting differently, because they are aware of being 
observed. People usually change their behavior under observation in such a way 
that they work faster and more diligently. This is important to be kept in mind when 
execution times have to be estimated. However, discovery based on observation has 
the advantage that it reveals how a process is conducted in reality today, which is in 
contrast to document analysis that typically captures the past. 

A third option of automatic process discovery emerges from the extensive op- 
erational support of business processes provided by various information systems. 
Automatic process discovery makes use of event logs that are stored by these infor- 
mation systems. Such event data have to be recorded in such a way that each event 
can be exactly related to three things: an individual case of the process, a specific 
activity of the process, and a precise point in time. If these three pieces of informa- 
tion are available in the event logs, then automatic process discovery techniques can 
be used to reconstruct the process model, for example for the online book retailer. 
Since this approach shares some characteristics with data mining, where meaning- 
ful information is extracted from fine-granular data, these techniques of automatic 
process discovery are subsumed to the research area of process mining. The advan- 
tage of automatic process discovery is that event logs capture the execution of a 
process very accurately including information about execution times. A limitation 
is though that some log information can be misleading. This may be the case if a 
system crashes such that logs are not stored correctly. These failure types relating to 
a flawed storage of event logs are summarized with the term noise. Furthermore, the 
models resulting from process mining may not be directly understandable. Process 
behavior can be very complex, such that the generated models are hardly readable. 
In such a case, the logs have to be filtered or clustered for getting models that help 
understanding the process. 


5.2.2 Interview-Based Discovery 


Interview-based discovery refers to methods that build on interviewing domain ex- 
perts about how a process is executed. With these methods, we have to explicitly 
take into account the challenges of process discovery, namely the fact that process 
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knowledge is scattered across different domain experts, that domain experts typi- 
cally think in terms of individual cases, and that domain experts are often not fa- 
miliar with business process modeling languages. This has implications for how the 
interviews can be scheduled, and which phases and iterations are required. 


Exercise 5.5 Consider that the order process of your favorite online book retailer 
has ten major activities that are conducted by different persons. How much time do 
you need approximately for creating a process model that is validated and approved 
by the process owner? Make appropriate assumptions. 


We have mentioned that process knowledge is typically fragmented due to spe- 
cialization and division of labor. For this reason, interviews have to be conducted 
with various domain experts involved in the process. As the process analyst might 
not yet understand the details of the involvement of different domain experts, it 
might be required to discover the process step by step. There are two strategies 
available for scheduling interviews: starting backwards from the products and re- 
sults of the process and starting at the beginning by proceeding forward. Conducting 
interviews in a forward way permits to follow the flow of processing in the order of 
how it unfolds. This is particularly helpful for understanding which decisions are 
taken at a given stage. However, following the processing in a backward way has 
also advantages. People working in a process require certain input to be available 
for conducting their work, and this perspective makes it easy to consider what has 
to be achieved before a specific activity can be conducted. Both perspectives, the 
downstream and the upstream perspective are important when interviewing domain 
experts. With each interview partner, it must be clarified which input is expected 
from prior upstream activities, which decisions are taken, and in which format the 
results of an activity are forwarded to which subsequent party. 

The discovery challenges emphasize that the expertise of the process analyst is 
required for abstracting information on how individual cases are executed in order 
to construct meaningful process models. Typically, the process analyst gathers in- 
formation about the process in interviews and later organizes the material offline 
before constructing an initial process model. As a consequence, interviewing a do- 
main expert is often conducted in different iterations. After an initial interview, the 
process analysts creates a draft process model, which is then discussed with the do- 
main expert in terms of correctness and completeness. Here, it is important to ask 
what happens if something goes wrong or how unexpected cases are handled. This 
feedback interview usually triggers another round of rework. In some cases, the sec- 
ond feedback round leads to an approval of the process model. In other cases, a third 
feedback round is required for checking the reworked process model again. Often, 
domain experts feel more comfortable with free-form interviews where they can dis- 
cuss the process at a level of detail that they find appropriate. Structured interviews, 
in contrast, can create a feeling of running through a checklist, with the effect that 
domain experts hold back important information that they are not explicitly asked 
for. 

It is a strength of interview-based discovery that the interview situation provides 
a rich and detailed picture of the process and the people working in it. It has the 
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potential to reveal inconsistent perceptions that different domain experts may have 
on how a process operates. It also helps the process analyst to understand the process 
in detail. However, it is a labor-intensive discovery method. Several iterations are 
required for arriving at a point where domain experts feel comfortable with how a 
process is described in a process model. 

One recurrent pitfall of interviews is that when asked how a given process or ac- 
tivity is performed, the interviewee tends to describe the normal way of processing. 
Thus, exceptions tend to be left aside. In other words, the interview ends up cover- 
ing only the “sunny-day” scenario. One way to prevent this pitfall is to reserve time 
during the interview to focus on the “rainy-day” scenarios. Questions that can be 
used to spark discussion on the rainy-day scenario are: “How did you handle your 
most difficult customer?”, “What was the most difficult case you have worked on?”. 
This technique allows one to uncover variations or exceptions in the process that, 
while not necessarily frequent, have a sufficient impact on the process to be worth 
documenting. 


5.2.3. Workshop-Based Discovery 


Workshop-based discovery also offers the opportunity to get a rich set of informa- 
tion on the business process. Although this is not always the case, the setting can 
be organized in such a way that the contributions to the discussion are immediately 
used to model the process. In contrast to interviews, it not only involves more partic- 
ipants, but also a bigger set of roles. Additional roles are required for facilitating the 
discussion and for operating the process modeling tool. The facilitator takes care 
of organizing the verbal contributions of the participants. The tool operator is re- 
sponsible for directly entering the discussion results into the modeling tool. Several 
domain experts also participate, as much as the process owner and the process an- 
alyst. The involvement to this extensive set of persons requires diligent preparation 
and scheduling. Furthermore, the process will not be sketched out in detail in only 
one session. It can be expected that three to five half-day sessions are required. 

At the start of a process discovery effort, when there is not yet information avail- 
able for modeling the process, it can be beneficial to take a more lightweight and 
participative approach to organizing the workshops. One technique to engage the 
workshop participants in the discovery effort is by asking workshop participants to 
build a map of the process using sticky notes. The facilitator starts with a pad of 
sticky notes. Each sticky note is meant to represent a task or event. The group starts 
to discuss how the process typically starts. The facilitator then writes the name of the 
(supposedly) first task or event into a sticky note and posts it on the wall. Then the 
facilitator asks what can happen next. The participants start mentioning one or more 
possible tasks. The facilitator writes these activities in new sticky notes and starts 
posting these on the wall, organizing them for example from left to right or top to 
bottom to capture the order of the activities. At this stage no lines are drawn between 
the tasks and no gateways are discovered. The purpose of this exercise is to build 
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Table 5.2 Relative strengths and limitations of process discovery methods 


Aspect Evidence Interview Workshop 
Objectivity high medium-high medium-high 
Richness medium high high 

Time Consumption low-medium medium medium 
Immediacy of Feedback low high high 


a map of activities and their temporal ordering. Sometimes, participants disagree on 
whether something is one task or two tasks. If the disagreement cannot be resolved, 
the two tasks can be written as two sticky notes and these two related sticky notes are 
pasted next to each other. The facilitator also needs to pay attention to the fact that 
the tasks being posted should be at the same level of detail. When people start men- 
tioning small micro-steps, like “putting the document on a fax machine” the facilita- 
tor should try to lift the level of abstraction. In the end, this exercise leads to a rough 
map that the process analyst can take as input for constructing an initial model. 


Exercise 5.6 Consider the following two companies. Company A is young, founded 
three years ago, and has grown rapidly to a current toll of 100 employees. Com- 
pany B is owned by the state and operates in a domain with extensive health and se- 
curity regulations. How might these different characteristics influence a workshop- 
based discovery approach? 


Workshop-based process discovery requires an organized facilitation and an at- 
mosphere of openness. In terms of facilitation, the facilitator has to ensure that the 
parole is balanced between the different participants. This means on the one hand 
restricting the speech time of talkative participants. On the other hand, more in- 
troverted participants should be encouraged to express their perspective. An atmo- 
sphere of openness is helpful for having everybody participate. This aspect is influ- 
enced by the culture of the company. In organizations with a strongly emphasized 
hierarchy, it might be difficult for domain experts to express their view openly if 
their supervisor is present. If creativity and independent thinking is appreciated in 
the company, the participants are likely to feel at ease with discussing issues. It is 
the responsibility of the facilitator to stimulate a constructive workshop interaction 
in both cases. In this case, workshops have the potential to resolve inconsistencies 
directly with all involved parties. 


5.2.4 Strengths and Limitations 


The different methods of process discovery have strengths and limitations. These 
can be discussed in terms of objectivity, richness, time consumption, and immediacy 
of feedback (see Table 5.2). 
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e Objectivity: Evidence-based discovery methods typically provide the best level 
of objectivity. Existing documents, existing logs and observation provide an un- 
biased account of how a process works. Interview-based and workshop-based dis- 
covery both have to rely on the descriptions and interpretations of domain experts 
who are involved with the process. This bears the risk that those persons may 
have perceptions and ideas of how the process operates, which may be partially 
not correct. Even worse, the process analyst is also at risk that domain experts 
might opportunistically hide relevant information about the process. This can be 
the case if the process discovery project happens in a political environment where 
groups of process stakeholders have to fear loss of power, loss of influence, or 
loss of position. 

e Richness: While interview-based and workshop-based discovery methods show 
some limitations in terms of objectivity, they are typically strong in providing rich 
insights into the process. Domain experts involved in interviews and workshops 
are a good source to clarify reasons and objectives for why a process is set up as it 
is. Evidence-based methods might show issues that need to be discussed and raise 
questions, but they often do not provide an answer. Talking to domain experts also 
offers a view into the history of the process and the surrounding organization. This 
is important for understanding which stakeholders have which agenda. Evidence- 
based discovery methods sometimes provide insight into strategic considerations 
about a process when they are documented in white papers, but they hardly allow 
conclusions about the personal agendas of the different stakeholders. 

e Time consumption: Discovery methods differ in the amount of time they require. 
While documentation of a company and a particular process can be easily made 
available to a process analyst, it is much more time-consuming to conduct in- 
terviews and workshops. While interview-based discovery suffers from several 
feedback iterations, it is difficult to schedule workshops with various domain ex- 
perts on short notice. Automatic process discovery often involves a significant 
amount of time for extracting, reformatting, and filtering of event logs. Passive 
observation also requires coordination and approval time. Therefore, it is a good 
idea to start with document analysis, since documentation can often be made ac- 
cessible on short notice. 

e Immediacy of feedback: Those methods that directly build on the conversation 
and interaction with domain experts are best for getting immediate feedback. 
Workshop-based discovery is best in this regard since inconsistent perceptions 
about the operation of a process can be directly resolved by the involved parties. 
Interviews offer the opportunity for asking questions whenever process-related 
aspects are unclear. However, not all issues can be directly resolved with a single 
domain expert. Evidence-based discovery methods raise various questions about 
how a process works. These questions can often only be answered by talking to 
domain experts. 


Since each discovery method has strengths and limitations, it is recommended to 
utilize a mixture of them in a discovery project. The process analyst typically starts 
with documentation that is readily available. It is essential to organize the project in 
such a way that the information can be gathered from the relevant domain experts 
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in an efficient and effective way. Interviews and workshops have to be scheduled 
during the usual work time of domain experts. Therefore, they have to be motivated 
to participate and involved in such a way that it is the least time-consuming for 
them. Once issues arise about specific details of a process, it might be required to 
turn back to evidence-based discovery methods. 


Exercise 5.7 In what situations is it simply not possible to use one or more of the 
described discovery methods? 


5.3 Process Modeling Method 


Modeling a process in the discovery phase is a complex task. Therefore, it is good 
to follow a predefined procedure in order to approach this task in a systematic way. 
One way to do so is to work in five stages, as follows: 


Identify the process boundaries 
Identify activities and events 

Identify resources and their handovers 
Identify the control flow 

Identify additional elements 


ed ale ara 


5.3.1 Identify the Process Boundaries 


The identification of the process boundaries is essential for understanding the scope 
of the process. Part of this work might have been done already with the definition 
of a process architecture. Technically, this means we need to identify the events 
that trigger our processes and those that identify the possible process outcomes. 
For example, let us consider again the order fulfillment process that we modeled in 
Chap. 3. We observe that this process is triggered by the receipt of a purchase order 
from the customer, and completes with the fulfillment of the order as an outcome. 
These two events mark the boundaries of this process. Accordingly, we use a start 
message event and an end event in BPMN to represent them. If our process would 
have had negative outcomes, we would have modeled these via terminate end events. 


5.3.2 Identify Activities and Events 


The goal of the second step is to identify the main activities of the process. The 
advantage of starting with the activities is that domain experts will clearly be able 
to state what they are doing even if they are not aware of working as part of an 
overarching business process. Also documents might explicitly mention activities, 
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Fig. 5.1 The main activities and events of the order fulfillment process 


for instance a set of work instructions. In the case of the order fulfillment process, 
this stage may lead to a set of activities for which the order and routing conditions 
are not yet defined. In this step, we also need to identify the events that occur during 
the process, which we will model with intermediate events. Figure 5.1 lists the 12 
activities of our example.! Note that this initial set of activities and events may 
undergo revisions, e.g. more activities may be added as we add more details into 
our model. If the process is too complex, we suggest to focus on the main activities 
and events only at this stage, and add the others at a later stage when a deeper 
understanding of these elements and their relations has been gained. 


5.3.3 Identify Resources and Their Handovers 


Once we have defined the set of main activities and events, we can turn to the ques- 
tion of who is responsible for them. This information provides the basis for the 
definition of pools and lanes, and the assignment of activities and events to one of 
these pools and lanes. At this stage, the order of the activities is not defined yet. 
Therefore, it is a good step to first identify those points in the process where work 
is handed over from one resource to another, e.g. from one department to the other. 
These handover points are important since a participant being assigned a new task 
to perform, usually has to make assumptions about what has been completed be- 
fore. Making these assumptions explicit is an essential step in process discovery. 
Figure 5.2 shows the set of activities and events of the order fulfillment process now 
being assigned to pools and lanes. The sequence flows indicate handover points. The 
handover points also help to identify parts of the process which can be studied in 
isolation from the rest. These parts can be refined into sub-processes with the help 
of the involved stakeholders. For example, in the order fulfillment process the acqui- 
sition of raw materials (cf. Fig. 4.19) could be handled in isolation from the rest of 
the process, since this part involves the suppliers and personnel from the warehouse 
& distribution department. 


'For simplicity, we only consider one supplier in this example, so for instance there is only one 
activity “Request raw materials” instead of “Request raw materials from Supplier 1” and “Request 
raw materials from Supplier 2”. 
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Fig. 5.2. The activities and events of the order fulfillment process assigned to pools and lanes 
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5.3.4 Identify the Control Flow 


The handover points define an initial structure for the control flow. In essence, con- 
trol flow relates to the questions of when and why activities and events are executed. 
Technically, we need to identify order dependencies, decision points, concurrent ex- 
ecution of activities and events and potential reword and repetition. Decision points 
require the addition of (X)OR-splits, and relevant conditions on the alternative se- 
quence flows. Rework and repetition can be modeled with loop structures. Concur- 
rent activities that can be executed independently from each other are linked to AND 
gateways. Event-based splits are used to react to decisions taken outside the process. 
If we have modeled more than one business party in the previous step via the use of 
multiple pools in this step we also need to capture the exchange of information be- 
tween the various pools via message flows. Figure 5.3 shows how order constraints 
are captured by control-flow arcs in the order fulfillment process. Here we can see 
that the handovers that we identified in the previous step have now been refined in 
more elaborate dependencies. 


Exercise 5.8 What is the relationship between the type of a gateway and the condi- 
tions of the subsequent arcs? 


5.3.5 Identify Additional Elements 


Finally, we can extend the model by capturing the involved artifacts and exception 
handlers. For the artifacts, this means adding data objects, data stores and their rela- 
tions to activities and events via data associations. For the exception handlers, this 
means using boundary events, exception flows and compensation handlers. As we 
mentioned in Chaps. 3 and 4, the addition of data elements and exceptions, depends 
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on the particular modeling purpose. For example, if the process is meant to be au- 
tomated, it is desirable to explicitly capture data and exception aspects. In this step 
we may also add further annotations to help support specific application scenarios, 
for instance, if the model is used for risk analysis or for process cost estimation we 
may need to add risk and cost information. In general, which elements to be added 
depends upon the particular application scenario. 

In this section we illustrated a method for constructing a business process model 
via a number of incremental steps. In a scenario where multiple business parties 
are involved, an alternative option is to start with a choreography diagram first, and 
then incrementally refine this diagram into a collaboration diagram. In this case, 
we use the choreography diagram to identify the resources first, and model each of 
them via a pool. Next, inside each pool we model those events and activities that 
handle handover of information between parties (i.e. send and receive activities, 
message and signal events); we can derive these elements from the activities of the 
choreography diagram. We can then continue with Step 2 of the above method by 
adding the other internal activities. Next, in Step 3 we model the inner resources 
within each party using lanes, and then continue with the rest of the method as 
normal. 


5.4 Process Model Quality Assurance 


Process discovery involves at least a process analyst and various domain experts. 
Since gathering information and organizing it in a process model is often done in a 
sequential way, and not simultaneously, there is a need for various steps of quality 
assurance. Here, we focus on syntactic, semantic and pragmatic quality. Figure 5.4 
shows that verification is used to achieve syntactic quality, validation provides se- 
mantic quality, and certification ensures pragmatic quality. Modeling guidelines and 
conventions help to ensure a good quality right from the start. 


5.4.1 Syntactic Quality and Verification 


Process models constructed in process discovery projects typically have to adhere 
to syntactical rules and guidelines. Syntactic quality relates to the goal of producing 
a process model that conforms to these rules. First of all, this means that the content 
of the model should comply with the syntax as defined by the process modeling lan- 
guage in use. For instance, in BPMN it is not allowed to draw a sequence flow across 
the boundaries of pools. BPMN defines an extensive set of syntax rules. Following 
these rules helps to make sure that a process model can always be interpreted. Be- 
yond that, many companies define guidelines in order to guarantee consistency and 
comparability of process models, which we will discuss below. 

Verification essentially addresses formal properties of a model that can be 
checked without knowing the real-world process. In the context of process model 
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Fig. 5.4 Quality aspects and quality assurance activities 


verification, structural and behavioral correctness can be distinguished. Structural 
correctness relates to the types of element that are used in the model and how they 
are connected. For instance, an activity should always have an incoming and an out- 
going arc and every element should be on a path from a start event to an end event 
of the process model. Such properties can often be checked quite easily by inspect- 
ing the graph-based structure of the process model. Behavioral correctness relates 
to potential sequences of execution as defined by the process model. It is a general 
assumption that a case should never be able to reach a deadlock or a livelock. This 
is the case when the soundness property holds (see Chap. 3). Common sound and 
unsound process fragments are depicted in Fig. 5.5. Verification properties such as 
soundness can be checked after a process model is created. Alternatively, a process 
modeling tool can enforce that a model is correct by design. This can be achieved by 
allowing only edit operations on the model that preserve structural and behavioral 
correctness. 


Exercise 5.9 Have a look at Fig. 5.5. Explain what exactly is going wrong in the 
unsound process model fragments. 


5.4.2 Semantic Quality and Validation 


Semantic quality relates to the goal of producing models that make true statements 
about the considered domain, either for existing as-is processes or future to-be pro- 
cesses. The particular challenge of a semantic quality assessment is that the process 
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Fig. 5.5 Common sound and unsound process fragments 


model has to be compared with the real-world domain of a particular business pro- 
cess. This means there is no set of formal rules that can be used to easily check 
semantic quality. Whether the process model at the center of Fig. 5.4 is of good 
semantic quality can only be assessed by talking to people involved in the process 
and by consulting documentation. 

Validation deals with checking the semantic quality of a model by comparing 
it with the real-world business process. There are two essential aspects of seman- 
tic quality: validity and completeness indexCompleteness. Validity means that all 
statements included in the model are correct and relevant to the problem. Validity 
can be assessed by explaining domain experts how the processing is captured in the 
model. The domain expert is expected to point out any difference between what the 
model states and what is possible in reality. Completeness means that the model 
contains all relevant statements on a process that would be correct. Completeness 
is more difficult to assess. Here, the process analyst has to ask about various alter- 
native processing options at different stages of the process. For example, the model 
in Fig. 5.3 is still missing all data elements and exception handlers. It is the job of 
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the process analyst to judge the relevance of these additional elements. This judg- 
ment has to be done against the background of the modeling objective, which the 
process analyst should be familiar with. Let us consider an example to understand 
the difference between validity and completeness. If the process model for loan as- 
sessments expresses that any financial officer may carry out the task of checking 
the credit history of a particular applicant while in practice this requires a specific 
authorization, the model has an issue with semantic quality (invalid statement). If 
the task of checking the credit history is omitted then it has a semantic problem due 
to incompleteness. Validation can be supported by techniques like simulation or in- 
terviews. Alternatively, there are tools that provide truthfulness by design. This is, 
for instance, achieved by building a process model from the logs of an information 
system, as we will see in Chap. 10. In practice, process models often require the 
approval from the process owner. This approval is a special validation step, since 
it again refers to the correctness and completeness of the process model. Beyond 
that, the approval of the process owner establishes the normative character of the 
process model at hand. As a consequence, the process model can now be archived, 
published or used as an input for process redesign. 


5.4.3 Pragmatic Quality and Certification 


Pragmatic quality relates to the goal of building a process model of good usability. 
The particular challenge of pragmatic quality assessment is to prognosticate the 
actual usage of a process model beforehand. Accordingly, this aspect very much 
focuses on how people interact with a model. Whether the process model at the 
center of Fig. 5.4 is of good pragmatic quality can, for instance, be checked by 
testing how well a user understands the content of the model. 

Certification is the activity of checking the pragmatic quality of a process model 
by investigating its usage. There are several aspects of usability including under- 
standability, maintainability, and learning. Understandability relates to the fact how 
easy it is to read a specific process model. Maintainability points to the ease of ap- 
plying changes to a process model. Learning relates to the degree of how good a 
process model reveals how a business process works in reality. There are several 
characteristics of a model that influence usability including its size, its structural 
complexity, and its graphical layout. Certification can be conducted using user in- 
terviews or user experiments. Alternatively, there are rules that strive to provide 
usability by design. This can be achieved, for instance, by following design rules on 
the structure of the process model. There are two essential checks for understanding, 
maintainability and learning. The first one relates to the consistency between visual 
structure and logical structure. Figure 5.6 and Fig. 5.7 show the same fragment of 
the order fulfillment process model. The second model is a rework of the first one 
in terms of layout. Here, the element positions have been changed with the aim to 
improve the consistency between visual structure and logical structure. The second 
check is concerned with meaningful labels. It is important that activities and other 
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Fig. 5.6 Extract of the order fulfillment process model with bad layout 
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Fig. 5.7 Extract of the order fulfillment process model with good layout 


elements have labels that follow specific naming conventions, as those presented in 
Sect. 3.1. 


5.4.4 Modeling Guidelines and Conventions 


Modeling guidelines and conventions are an important tool for safeguarding model 
consistency and integrity for bigger modeling initiatives with several people in- 
volved. The goals of such guidelines and conventions are to increase readability 
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and comparability in order to facilitate efficient model analysis. A guideline docu- 
ment typically covers naming conventions for processes, tasks and events, modeling 
conventions for layout and usage of tasks, events, lanes and pools, and a restric- 
tion of the set of elements. Naming conventions usually recommend or enforce the 
verb-object style for labeling of activities and suitable styles for other elements as 
discussed in Sect. 3.1. Too technical and too generic verbs should be avoided. Mod- 
eling conventions define element usage and layout. Layout for BPMN models is 
typically defined with a horizontal orientation. Usage of pools may be enforced for 
each model along with corresponding message flow. The detail of how start and end 
events are captured can be specified as well. All the conventions often come along 
with rules how to capitalize or what to reference in the elements names, e.g. using a 
glossary. Finally, restrictions can be defined in order to simplify the set of elements 
of BPMN. Such restrictions are recommended to increase understanding of models 
also by non-expert users. 

One set of guidelines that has recently been proposed are the so-called Seven 
Process Modeling Guidelines (7PMG). This set was developed as an amalgamation 
of the insights that were derived from available research. Specifically, the analysis 
of large sets of process models by various researchers have identified many syn- 
tactical errors as well as complex structures that inhibited their interpretation. The 
guidelines that are part of 7PMG are helpful in guiding users towards mitigating 
such problems. The guidelines are as follows: 


G1: Use as few elements in the model as possible. The size of a process model has 
undesirable effects on the understanding of process model and the likelihood 
of syntactical errors. Studies have shown that larger models tend to be more 
difficult to understand and have a higher error rate. 

G2: Minimize the routing paths per element. For each element in a process model, 
it is possible to determine the number of incoming and outgoing arcs. This 
summed figure gives an idea of the routing paths through such an element. 
A high number makes it harder to understand the model. Also, the number 
of syntactical errors in a model seems strongly correlated to the use of model 
elements with high numbers of routing paths. 

G3: Use one start and one end event. Empirical studies have established that the 
number of start and end events is positively connected with an increase in error 
probability. Models satisfying this requirement are easier to understand and 
allow for all kinds of formal analysis. 

G4: Model as structured as possible. A process model is structured if each split 
gateway matches a respective join gateway of the same type. Block-structured 
models can be seen as formulas with balanced brackets, i.e., every opening 
bracket has a corresponding closing bracket of the same type . Unstructured 
models are not only more likely to include errors, people also tend to under- 
stand them less easily. Nonetheless, as discussed in Chap. 4.3, it is sometimes 
not possible or not desirable to turn an unstructured process model fragment 
(e.g. an unstructured cycle) into a structured one. This is why this guideline 
states “as structured as possible”. 
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Fig. 5.8 A complaint handling process as found in practice 


G5: Avoid OR-gateways. Models that have only AND-gateways and XOR-gate- 
ways are less error-prone. This empirical finding is apparently related to the 
fact that the combinations of choices represented by an OR-split are more dif- 
ficult to grasp than behavior captured by other gateways. 

G6: Use verb-object activity labels. A wide exploration of labeling styles that are 
used in actual process models, discloses the existence of a number of popular 
styles. From these, people consider the verb-object style, like “Inform com- 
plainant’, as significantly less ambiguous and more useful than action-noun 
labels (e.g. “Complaint analysis”) or labels that follow neither of these styles 
(e.g. “Incident agenda’’). 

G7: Decompose a model with more than 30 elements. This guideline relates to G1 
that is motivated by a positive correlation between size and errors. For mod- 
els with a more than 30 elements the error probability tends to climb sharply. 
Therefore, large models should be split up into smaller models. For example, 
large sub-components with a single entry and a single exit can be replaced by 
one activity that points to the original sub-component as a sub-process. 


The need for guidelines like 7PMG is emphasized by the structure of process 
models we have seen in practice. Figure 5.8 shows a simplified version of a com- 
plaint handling process model of one of our industry partners. A complaint is trig- 
gered by a phone call by a complaining customer. It is decided whether the com- 
plaint can be handled or whether it has to be referred to an internal or external party. 
An external referral leads to a telephone confirmation to the external party. An in- 
ternal referral is added to the incident agenda. If no referral is needed, a complaint 
analysis is conducted and the complainant is contacted. In either case, the complaint 
is archived and the case is closed. 


Exercise 5.10 Consider the process model of Fig. 5.8. Explain which 7PMG guide- 
lines point to potential for improvement. Remodel the process based on your obser- 
vations. 
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The 7PMG are but one of the available sets of modeling guidelines. Moreover, 
it is a tentative set in the sense that research in the area of process model quality 
is rapidly developing. Many of its guidelines are already applied in practice and 
have been discussed as state-of-the-art at previous places in this book. For example, 
in Sect. 3.1 the beneficial verb-object labeling convention was already mentioned. 
Also, the threshold to start decomposing process models as in guideline G7 was 
discussed in Sect. 4.1. What is special about the 7PMG is that these guidelines 
have a strong empirical basis and, as such, transcend the knowledge of individual 
modelers. As insights develop further, it seems both likely and favorable that the set 
will be updated and expanded. 


5.5 Recap 


This chapter described how to proceed in the different phases of process discov- 
ery. In essence, we defined four stages of process discovery, namely defining the 
setting of process discovery, applying different discovery methods for gathering in- 
formation about the process, stepwise modeling the process, and finally addressing 
different aspects of quality assurance. 

The definition of the setting of process discovery has to take into account the 
different characteristics and complementary skills of process analysts and domain 
experts. While process analysts are skilled in analyzing and modeling processes, 
they often lack detailed domain knowledge. In contrast, domain experts have typi- 
cally limited modeling skills, but detailed understanding of the part of the process 
they are involved with. This implies three challenges of process discovery. First, 
different domain experts have an understanding of only a part of the process. Differ- 
ent partial views have to be integrated in process discovery. Second, domain experts 
tend to think in cases and not on the general process level. The process analyst has 
to abstract from these cases. Third, domain experts often have difficulties in under- 
standing process models. Therefore, the process analyst has to guide the domain 
expert in reading the model for getting feedback. 

Different methods of process discovery can be used ranging from evidence-based 
methods to interviews and workshops. Evidence-based methods typically provide 
the most objective insight into the execution of the process. However, the immedi- 
acy of feedback is low and the richness of the insight can be mediocre. Interviews 
can be biased towards the perspective or opinion of the interview partner, but re- 
veal rich details of the process. The interview situation offers the chance of direct 
feedback and clarification. Workshops can help to immediately resolve inconsistent 
perspectives of different domain experts. On the downside, it is difficult to have 
all required domain experts synchronously joining. It is recommended to utilize a 
mixture of the methods that reflects the specifics of the discovery project. 

We then defined a process modeling method including six steps. First, the bound- 
aries of the process have to be defined in terms of start and end events. Second, the 
essential activities of the process have to be identified. Subsequently, we need to de- 
termine the handovers between different persons and departments. Once that aspect 
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is clarified, we can sketch out the details of the control flow. Then, routing condi- 
tions and intermediate events have to be added. Finally, additional perspectives and 
annotations can be included. 

In the last sections of this chapter, we discussed different measures of quality 
assurance. First, we emphasized verification as a tool for assuring syntactical cor- 
rectness. Then, we discussed how validation helps to establish semantic quality. 
Finally, we presented different aspects of pragmatic quality and described how they 
can be certified. 


5.6 Solutions to Exercises 


Solution 5.1 In case you are supposed to map the process of signing a rental con- 
tract in your city, it is likely that you have some experience with this process, either 
from renting a flat yourself, or from stories from your friends, or from you or your 
friends giving a flat for rent. Assuming you have already studied the chapters on 
process modeling, you have both domain expertise and process modeling expertise. 
This is an uncommon situation. Most often, you face situations like mapping the 
process of getting a license plate for your car in Liechtenstein as a foreign resident. 
This is a process for which you would unlikely have domain knowledge. Process 
discovery typically brings you as a process analyst into an environment that you do 
not know in detail beforehand. Process discovery is concerned with understanding 
the process under consideration and also the domain surrounding it. 


Solution 5.2 An advantage of having teams modeling processes themselves is first 
that a lot of process models can be created in a short span of time. It is critical 
though that these teams possess the required skills in process modeling. According 
to the third challenge of process discovery, domain experts typically do not have pro- 
cess modeling skills and feel uncomfortable with the modeling task. Furthermore, 
domain experts often think in cases (second challenge) and lack the process per- 
spective to generalize. Finally, there is the risk that the results from such a modeling 
initiative might be fragmented and difficult to integrate. It is typically the responsi- 
bility of the process analyst to integrate the fragmented perspectives. 


Solution 5.3 Domain knowledge can be very helpful for analyzing processes. It 
helps to ask the right questions and to build analogies from prior experience. On 
the other hand, the skills of an experienced process analyst should not be underes- 
timated. These skills are domain-independent and relate to how a process discovery 
project can be organized. Experienced process analysts are typically very skilled in 
scoping and driving a project into the right direction. They possess problem-solving 
skills for handling various critical situations of a process discovery project. There 
is clearly a trade-off between the two sets of skills. It should be ensured that a cer- 
tain level of process analysis experience is available. If that is not the case for the 
applying domain expert, the process analyst might be preferred. 
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Solution 5.4 As a customer, we would have to rely mostly on evidence-based pro- 
cess discovery. We can place exemplary orders and study the different processing 
options for them. In relation to these placed orders, we could also contact the cus- 
tomer help desk and inquire details of the process that we cannot directly observe. 
If we were assigned to a process discovery project by the process owner, we would 
get access to the domain experts within the company. In this case, we could also use 
interviews and workshop-based discovery methods. 


Solution 5.5 This process contains ten major activities that are executed by differ- 
ent persons. We can assume that there will be a kickoff meeting with the process 
owner and some important domain experts on day one. One day might be required 
to study available documentation. An interview with one domain expert can take 
from two to three hours, such that we would be able to meet two persons per day, 
and document the interview results at night time. Let us assume that we meet some 
persons only once while we seek feedback from important domain experts in two 
additional interviews. Then, there would be a final approval from the process owner. 
This adds up to one day for the kickoff, one for document study, five days for the 
first iteration interviews, and further five days if we assume that we meet five experts 
three times. Then, we need one day for preparing the meeting for final approval with 
the process owner, which would be on the following day. If there are no delays and 
scheduling problems, this yields 2 + 5 +5 +2 = 14 work days as a minimum. 


Solution 5.6 Before starting with process discovery, it is important to understand 
the culture and the sentiment of an organization. There are companies that preach 
and practice an open culture in which all employee are encouraged to utter their 
ideas and their criticism. Such organizations can benefit a lot from workshops as 
participants are likely to present their ideas freely. In strictly hierarchical organiza- 
tions, it is necessary to take special care that every participant gets an equal share of 
parole in a workshop and that ideas and critique are not hold back. It might be the 
case that the young dynamic company has a more open culture than the company 
with extensive health and security regulations. This has to be taken into account 
when organizing a workshop. 


Solution 5.7 There are various circumstances that may restrict the application of 
different discovery methods. Direct observation may not be possible if the process 
partially runs in a remote or dangerous environment. For instance, the discovery of a 
process of an oil-producing company for pumping oil from an oil rig to a ship might 
belong to this category. Then, there might be cases where documentation does not 
exist, for example when a startup company, which has gone through a period of 
rapid growth wants to structure its purchasing process. Lack of input may also be 
a problem for automatic process discovery based on event log data. If the process 
under consideration is not yet supported by information systems, then there are no 
data available for conducting automatic process discovery. In general, interviews 
are always possible. It might still be a problem though to gain commitment of do- 
main experts for an interview. This is typically the case when the process discovery 
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project is subject to company-internal politics and hidden agendas. Workshop-based 
discovery can be critical in companies with strong hierarchy which have a culture 
of suppressing creative thinking of their staff. 


Solution 5.8 The type of the gateway has to be consistent with the conditions of the 
subsequent arcs. If there is an XOR-split, then the conditions on the arcs have to be 
mutually exclusive. If there is an OR-split, then the conditions can be non-exclusive. 
If an AND-split is used, there should be no conditions on the arcs. 


Solution 5.9 Four unsound fragments are shown with the following problems: 


e The lack of synchronization relates to an AND-split followed by an XOR-join. In 
this case, the two tokens created from the AND-split are not synchronized XOR- 
join, potentially leading to the duplicate execution of activities downstream. 

e A deadlock occurs, for instance, if an XOR-split is followed by an AND-join. 
As the XOR-split creates a token only on one of its outgoing arcs, the AND-join 
requiring a token on each of its incoming arcs gets stuck waiting for a second 
token to arrive. 

e Incase there is an OR-split followed by an XOR-join, we potentially get a lack 
of synchronization. This depends upon the conditions of the OR-split. If only one 
token is generated from it, the process can proceed correctly. If multiple tokens 
are generated, there is a lack of synchronization. In the same vein, there is a 
potential deadlock if the OR-split is followed by an AND-join. 

e A livelock can occur in an inappropriate loop structure. Here, there is an XOR- 
join used as an entry to a loop, but the loop exit is modeled with an AND-split. 
This has the consequence that it is never possible to leave the loop. Each time the 
AND-split is reached, it creates one token exiting the loop, but also another token 
that stays within the loop. 


Solution 5.10 The process model reveals several problems. Several elements with 
the same name are shown twice (end event and archiving activity), therefore G1 is 
violated. Also the control structure is very complicated, violating G4 asking for a 
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Fig. 5.9 The complaint handling process reworked 
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Fig. 5.10 A loan application process 


structured model. Finally, several activities do not follow the naming conventions 
of G6.The model can be reworked and simplified to the one shown in Fig. 5.9. 


5.7 Further Exercises 


Exercise 5.11 Imagine you are responsible for the human resources department 
of a leading consultancy. Which characteristics would you check when hiring new 
process analysts? 


Exercise 5.12 As responsible for human resources department of a consultancy, 
how would you develop the skills of your junior process analysts? 


Exercise 5.13. How would you as a process analyst prepare for an interview with a 
domain expert? 


Exercise 5.14 Analyze the loan application process model of Fig. 5.10 for 
soundness-related problems. 


Exercise 5.15 Look up tools on the internet that offer a soundness check for process 
models. 


Exercise 5.16 Consider again the loan application process model of Fig. 5.10. What 
are indications that it would not be complete? 


Exercise 5.17 Have a look at the activity labels of the loan application model of 
Fig. 5.10 and propose improved labels where appropriate. 


Exercise 5.18 Have a look at the process model of Fig. 5.10 showing a sales cam- 
paign process for one of our industry partners. Describe which 7PMG guidelines 
can be used to improve this model. Have a look at the process model of Fig. 5.11 
showing a sales campaign process for one of our industry partners 
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Fig. 5.11 A sales campaign process 


5.8 Further Reading 


The general topic of process discovery is well covered in the book on workflow mod- 
eling by Sharp and McDermott [86]. This book gives detailed advice on all phases 
of process discovery, specifically data gathering and workshop organization. Other 
practical advice is summarized by Verner [101] and by Stirna, Persson, and Sand- 
kuhl [88]. Interview techniques are widely discussed as a social science research 
method for instance in the book by Berg and Lune [7] or the book by Seidman [85]. 

Frederiks and van der Weide [18] discuss the skills required from process an- 
alysts, particularly when engaging in process discovery efforts. In a similar vein, 
Schenk, Vitalari and Davis [83] and Petre [66] discuss the capabilities that expert 
process analysts (as opposed to novice ones) generally display when engaging in 
process discovery. 

In this chapter, we emphasized “manual” process discovery techniques, wherein 
process models are manually constructed based on data collected from various pro- 
cess stakeholders by means of interviews, workshops and related techniques. As 
mentioned in Sect. 5.2.1, there is also a whole range of complementary techniques 
for automatic discovery process models from event logs. These automatic process 
discovery techniques are part of a broader set of techniques for analyzing event logs, 
collectively known as process mining [94]. We will discuss several process mining 
techniques later in Chap. 10. 

The modeling method introduced in Sect. 5.3 revolves around the discovery of 
activities and control-flow relations between activities. This family of approaches 
is usually called activity-based modeling [68]. An alternative approach to pro- 
cess modeling is known as artifact-centric modeling [59] or object-centric mod- 
eling [68]. In artifact-centric modeling the emphasis is not on identifying activities, 
but rather artifacts (physical or electronic objects or documents) that are manip- 
ulated within a given process. For example, in an order-to-cash process, typical 
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artifacts are the purchase order, the shipment notice and the invoice. Once these 
artifacts have been identified, they are analyzed in terms of the data that they hold 
and in terms of the phases they go through during the process. For example, a pur- 
chase order typically goes through the phases received, accepted, manufactured, 
shipped and invoiced. These phases and the transitions between these phases are 
called the artifact lifecycle. The main emphasis in artifact-centric process model- 
ing is put on identifying these artifact lifecycles. Several industrial applications of 
artifact-centric process modeling have shown that it is quite suitable when discov- 
ering processes that exhibit significant amounts of variation, for example variation 
between business units, geographical regions or types of customer as discussed for 
example by Caswell et al. [59] and Redding et al. [68]. 

The quality of conceptual models in general, and of process models specifically, 
has received extensive attention in the research literature. The Sequal framework 
introduced by Lindland, Sindre, and S¢lvberg adapts semiotic theory, namely the 
three perspectives of syntax, semantics and pragmatics, to the evaluation of con- 
ceptual model quality [45]. An extended version of this framework is presented by 
Krogstie, Sindre, and Jgrgensen [42]. 

Validation and verification of process models has also received extensive atten- 
tion in the literature. Mendling [51] for example provides numerous pointers to re- 
lated research. The verification of Workflow nets specifically is investigated by van 
der Aalst [93] who connects soundness analysis of process models with classical 
Petri nets notions of liveness and boundedness. 

The 7PMG guidelines discussed in Sect. 5.4.4 are by Mendling, Reijers, and van 
der Aalst in [53]. These guidelines build on empirical work on the relation between 
process model metrics on the one hand and error probability and understandabil- 
ity on the other hand [50, 54, 55, 63, 73, 74]. Specifically, the impact of activity 
label quality on process model understanding is investigated by Mendling, Reijers, 
and Recker [52]. Another set of modeling guidelines are the Guidelines of Process 
Modeling by Becker et al. [5]. 

As a complement to process modeling guidelines and conventions, it is useful 
to also keep in mind potential pitfalls to be avoided in process modeling projects. 
For example, Rosemann [78, 79] draws a list of 22 pitfalls of process modeling, 
including a potential lack of strategic connection, l’art pour l'art, to name but a 
few. His bottom line is that modeling success does not directly equate with process 
success. 


Chapter 6 
Qualitative Process Analysis 


Quality is free, but only to those who are willing to pay heavily 
for it. 
Tom DeMarco (1940-) 


Analyzing business processes is both an art and a science. In this respect, qualita- 
tive analysis is the artistic side of process analysis. Like fine arts, such as painting, 
there is not a single way of producing a good process analysis, but rather a range 
of principles and techniques that tell us what practices typically lead to a “good” 
process analysis. When learning to paint, you learn how to hold the brush, how to 
produce different types of brushstroke, how to mix colors, etc. The rest of the art 
of painting is up to you to acquire by means of practice, discernment and critical 
self-assessment. 

In this chapter, we introduce a few basic principles and techniques for qualitative 
process analysis. First, we present principles aimed at making the process leaner by 
identifying unnecessary parts of the process in view of their elimination. Next, we 
present techniques to identify and analyze the weak parts of the process, meaning 
the parts that create issues that negatively affect the performance of the process. 
In particular, we discuss how to analyze the impact of issues in order to prioritize 
redesign efforts. 


6.1 Value-Added Analysis 


Value-added analysis typically consists of two stages: value classification and waste 
elimination. Below we discuss each of these stages in turn. 


6.1.1 Value Classification 


Value-added analysis is a technique aimed at identifying unnecessary steps in a pro- 
cess in view of eliminating them. In this context, a step may be a task in the process, 
or part of a task, or a handover between two tasks. For example, if a task “Check 
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purchase order” ends with the Purchase Order (PO) being sent by internal mail to a 
supervisor, and the next task “Approve purchase order’ starts when the supervisor 
receives and checks the PO, then we can say that the transportation of the PO via 
internal mail is a step—a potentially unnecessary (non-value-adding) step in this 
context. It is often the case that one task involves several steps. For example, a task 
“Check invoice” may involve the following steps: 


. Retrieve the PO(s) that corresponds to the invoice. 

. Check that the amounts in the invoice and those in the PO coincide. 

. Check that the products or services referenced in the PO have been delivered. 

. Check that the supplier’s name and banking details in the invoice coincide with 
those recorded in the Supplier Management System. 


BRWN rR 


In some cases, steps within a task are documented in the form of checklists. The 
checklists tell the process participants what things need to be in place before a task 
is considered to be complete. If detailed checklists are available, the process analyst 
can use them to decompose tasks into steps. Unfortunately, such checklists are not 
always available. In many cases, process participants have an implicit understand- 
ing of the steps in a task because they perform the task day in and day out. But this 
implicit understanding is not documented anywhere. In the absence of such docu- 
mentation, the process analyst needs to decompose each task into steps by means of 
observation and interviewing. 

Having decomposed the process into steps, a second prerequisite for value-added 
analysis is to identify who is the customer of the process and what are the positive 
outcomes that the customer seeks from the process (cf. Sect. 1.2). These outcomes 
are said to add value to the customer, in the sense that fulfilling these outcomes is in 
the interest or for the benefit of the customers. 

Having decomposed the process into steps and having clearly identified the pos- 
itive outcomes of a process, we can then analyze each step in terms of the value 
it adds. Steps that directly contribute to positive outcomes are called value-adding 
steps. For example, consider a process for repairing a washing machine or other 
domestic appliance. The steps in this process where the technician diagnoses the 
problem with the machine are clearly value-adding, as it directly contributes to the 
outcome the customer wishes to see, that is, that the machine is repaired. Also, the 
steps related to repairing the machine are value-adding. 

Some steps do not directly add value to the customer but they are necessary 
for the business. Consider again the example of a process for repairing a washing 
machine. Imagine that this process includes a step “Record defect” in which the 
technician enters data about the washing machine and an explanation of the defect 
found in a washing machine into an information system. This step per se is not 
value-adding for the customer. The customer wishes the machine to be fixed and 
does not get value by the fact that the defect in their machine was recorded in an 
information system of the repairing company. However, recording defects and their 
resolution helps the company to build up a knowledge base of typical defects and 
their resolution. This knowledge base is extremely valuable when new technicians 
are recruited in the company, since they can learn from knowledge that more expe- 
rienced technicians have recorded. Also, such information allows the company to 
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detect frequent defects and to report such defects to the manufacturer or distributor 
of the washing machine. Steps such as “Record defect” are termed business value- 
adding steps, in the sense that the customer is not willing to pay for the performance 
of these steps nor do they gain satisfaction from these steps being performed (so the 
steps are not value-adding) but the step is necessary or useful to the company that 
performs the process. 

In summary, value-added analysis is a technique whereby an analyst decorticates 
a process model, extracts every step in the process and classifies these steps into one 
of three categories, namely: 


e Value-adding (VA): This is a step that produces value or satisfaction vis-a-vis of 
the customer. When determining whether or not a step is value-adding, it may 
help to ask the following question: Would the customer be willing to pay for this 
activity? 

e Business value-adding (BVA): The step is necessary or useful for the business to 
run smoothly, or it is required due to the regulatory environment of the business. 

e Non-value adding (NVA): The step does not fall into any of the other two cate- 
gories. 


Example 6.1 We consider the process for equipment rental described in Exam- 
ple 1.1 (p. 2). As discussed in Sect. 1.2, the customer of this process is the site 
engineer who submits an equipment rental request. From the perspective of the site 
engineer, the positive outcome of the process is that the required piece of equipment 
is available in the construction site when needed. Let us analyze the fragment of this 
process described in Fig. 1.6. To identify the relevant steps, we will decorticate the 
model task by task. While we do this, we will also classify the steps into VA, BVA 
and NVA. 


e The first task in the process model is the one where the engineer lodges the re- 
quest. From the description in Example 1.1, we observe there are three steps in 
this task: 


1. Site engineer fills in the request. 
2. Site engineer sends the request to the clerk via e-mail (handover step). 
3. Clerk opens and reads the request (handover step). 


Arguably, filling the request is value-adding insofar as the site engineer cannot 
expect the equipment to be rented if they do not ask for it. In one way or another, 
the site engineer has to request the equipment in order to obtain it. On the other 
hand, the site engineer does not get value out of sending the request to the clerk by 
e-mail nor do they get value out of the clerk having to open and read the request. 
More generally, handover steps between process participants, such as sending and 
receiving internal messages, are not value-adding. 

e The second task is the one where the clerk selects a suitable equipment from the 
supplier’s catalog. We can treat this task as a single step. This step is value-adding 
insofar as it contributes to identifying a suitable equipment to fulfill the needs of 
the site engineer. 
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e Inthe third task, the clerk calls the supplier to check the availability of the selected 
equipment. Again, we can treat this task as a single step. This step is value-adding 
insofar as it contributes to identifying a suitable and available equipment. If the 
equipment is available, the clerk will recommend that this equipment be rented. 
To this end, the clerk adds the details of the recommended equipment and sup- 
plier to the rental request form and forwards the form to the works engineer for 
approval. Thus we have two more steps: (i) adding the details to the rental request 
and (ii) forwarding the rental request to the works engineer. The first of these 
steps is business value-adding since it helps the company to keep track of the 
equipment they rent and the suppliers they rent from. Maintaining this informa- 
tion is valuable when it comes to negotiating or re-negotiating bulk agreements 
with suppliers. The handover between the clerk and the works engineer is not 
value-adding. 

e Next, the works engineer examines the rental request in view of approving it 
or rejecting it. We can treat this examination as one step. This step is a control 
step, that is, a step where a process participant or a software application checks 
that something has been done correctly. In this case, this control step helps the 
company to ensure that equipment is only rented when it is needed and that the 
expenditure for equipment rental in a given construction project stays within the 
project’s budget. Control steps are generally business value-adding, although an 
analyst may ask the question of how many control steps are needed and how often 
they should be performed. 

e If the works engineer has an issue with the rental request, the works engineer 
communicates it to the clerk or the site engineer. This communication is another 
step and it is business value-adding since it contributes to identifying and avoiding 
misunderstandings within the company. If approved, the request is sent back to 
the clerk; this is a handover step and it is thus non-value-adding. 

e Finally, assuming the request is approved, the clerk produces and sends the PO. 
Here we can identify two more steps: produce the PO and send the PO to the cor- 
responding supplier. Producing the PO is business value-adding. It is necessary in 
order to ensure that the rental request cost is correctly accounted for and eventu- 
ally paid for. Sending the PO is value-adding: It is this act that makes the supplier 
know when the equipment has to be delivered on a given date. If the supplier did 
not get this information, the equipment would not be delivered. Note, however, 
that what is value-adding is the fact that the supplier is explicitly requested by the 
construction company to deliver the equipment on a given date. The fact that this 
request is made by sending a PO is secondary in terms of adding value to the site 
engineer. 


The identified steps and their classification are summarized in Table 6.1. 


Classifying steps into VA, BVA and NVA is to some extent subjective and de- 
pends on the context. For example, one may question whether producing the PO is 
a VA or a BVA step. Arguably, in order for the equipment to be available, the sup- 
plier needs to have an assurance that the equipment rental fee will be paid. So one 
could say that the production of the PO contributes to the rental of the equipment 
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Table 6.1 Classification of steps in the equipment rental process 


Step Performer Classification 
Fill request Site engineer VA 
Send request to clerk Site engineer NVA 
Open and read request Clerk NVA 
Select suitable equipment Clerk VA 
Check equipment availability Clerk VA 
Record recommended equipment & supplier Clerk VA 
Forward request to works engineer Clerk VA 
Open and examine request Works engineer BVA 
Communicate issues Works engineer BVA 
Forward request back to clerk Works engineer NVA 
Produce PO Clerk BVA 
Send PO to supplier Clerk BVA 


since the PO serves to assure the supplier that the payment for the rental equipment 
will be made. However, as mentioned above, what adds value to the site engineer 
is the fact that the supplier is notified that the equipment should be delivered at the 
required date. Whether this notification is done by means of a PO or by means of 
a simple electronic message sent to the supplier is irrelevant, so long as the equip- 
ment is delivered. Thus, producing a formal document (a formal PO) is arguably not 
value-adding. It is rather a mechanism to ensure that the construction company’s fi- 
nancial processes run smoothly and to avoid disputes with suppliers, e.g. avoiding 
the situation where a supplier delivers a piece of equipment that is not needed and 
then asks for payment of the rental fee. More generally, we will take the convention 
that steps imposed by accounting or legal requirements are BVA, even though one 
could argue differently in some cases. 


Exercise 6.1 Consider the process for university admission described in Exer- 
cise 1.1 (p. 4). What steps can you extract from this process? Classify these steps 
into VA, BVA and NVA. 


6.1.2 Waste Elimination 


Having identified and classified the steps of the process as discussed above, one 
can then proceed to determining how to eliminate waste. A general rule is that one 
should strive to minimize or eliminate NVA steps. Some NVA steps can be elimi- 
nated by means of automation. This is the case of handovers for example, which can 
be eliminated by putting in place an information system that allows all stakeholders 
to know what they need to do in order to move forward the rental requests. When 
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the site engineer submits a rental request via this information system, the request 
would automatically appear in the to-do list of the clerk. Similarly, when the clerk 
records the recommended supplier and equipment, the works engineer would be no- 
tified and directed to the request. This form of automation makes these NVA steps 
transparent to the performers of the steps. The topic of process automation will be 
discussed in further detail in Chap. 9. 

A more radical approach to eliminating NVA steps in the working example is 
to eliminate the clerk altogether from the process. This means moving some of the 
work to the site engineer so that there are less handovers in the process. Of course, 
the consequences of this change in terms of added workload to the site engineer need 
to be carefully considered. Yet another approach to eliminate NVA (and BVA) steps 
would be to eliminate the need for approval of rental requests in cases where the 
estimated cost is below a certain threshold. Again, this option should be weighted 
against the possible consequences of having less control steps in place. In particular, 
if the site engineers were given full discretion to rent equipment at their own will, 
there would need to be a mechanism in place to make them accountable in case 
they rent unnecessary equipment or they rent equipment for excessively and unnec- 
essarily long periods. Such process redesign questions will be further discussed in 
Chap. 8. 

While elimination of NVA steps is generally considered a desirable goal, elimi- 
nation of BVA steps should be considered as a trade-off given that BVA steps play a 
role in the business. Prior to eliminating BVA steps, one should first map BVA steps 
to business goals and business requirements, such as regulations that the company 
must comply to and risks that the company seeks to minimize. Given a mapping be- 
tween BVA steps on the one hand and business goals and requirements on the other, 
the question then becomes the following: What is the minimum amount of work 
required in order to perform the process to the satisfaction of the customer, while 
fulfilling the goals and requirements associated to the BVA steps in the process? The 
answer to this question is a starting point for process redesign. 


6.2 Root Cause Analysis 


When analyzing a business process, it is worth keeping in mind that “even a good 
process can be made better” [28]. Experience shows that any non-trivial business 
process, no matter how much improvement it has undergone, suffers from a number 
of issues. There are always errors, misunderstandings, incidents, unnecessary steps 
and other forms of waste when a business process is performed on a day-to-day 
basis. 

Part of the job of a process analyst is to identify and to document the issues that 
plague a process. To this end, an analyst will typically gather data from multiple 
sources and will interview several stakeholders, chiefly the process participants but 
also the process owner and managers of organizational units involved in the process. 
Each stakeholder has a different view on the process and will naturally have a ten- 
dency to raise issues from their own perspective. The same issue may be perceived 
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differently by two stakeholders. For example, an executive manager or a process 
owner will typically see issues in terms of performance objectives not being met or 
in terms of constraints imposed for example by external pressures (e.g. regulatory 
or compliance issues). Meanwhile, process participants might complain about in- 
sufficient resources, hectic timelines as well as errors or exceptions perceived to be 
caused by other process participants or by customers. 

Root cause analysis is a family of techniques to help analysts identify and un- 
derstand the root cause(s) of problems or undesirable events. Root cause analysis is 
not confined to business process analysis. In fact, root cause analysis is commonly 
used in the context of accident or incident analysis as well as in manufacturing pro- 
cesses where it is used to understand the root cause of defects in a product. In the 
context of business process analysis, root cause analysis is helpful to identify and to 
understand the issues that prevent a process from having a better performance. 

Root cause analysis encompasses a variety of techniques. In general, these meth- 
ods include guidelines for interviewing and conducting workshops with relevant 
stakeholders, as well as techniques to organize and to document the ideas generated 
during these interviews or workshops. Below, we will discuss two of these tech- 
niques, namely cause-and-effect diagrams and why—why diagrams. 


6.2.1 Cause-Effect Diagrams 


Cause-—effect diagrams depict the relationship between a given negative effect and 
its causes. In the context of process analysis, a negative effect is usually either a re- 
current issue or an undesirable level of process performance. Causes can be divided 
into causal and contributing factors (hereby called factors) as explained in the box 
below. 


CAUSAL VERSUS CONTRIBUTING FACTORS 

Two broad types of cause are generally distinguished in the area of root cause 
analysis, namely causal factors and contributing factors. Causal factors are 
those factors that, if corrected, eliminated or avoided would prevent the is- 
sue from occurring in future. For example, in the context of an insurance 
claims handling process, errors in the estimation of damages lead to incorrect 
claim assessments. If the damage estimation errors were eliminated, a number 
of occurrences of the issue “Incorrect claim assessment” would definitely be 
prevented. Contributing factors are those that set the stage for, or that increase 
the chances of a given issue occurring. For example, consider the case where 
the user interface for lodging the insurance claims requires the claimant to 
enter a few dates (e.g. the date when the claim incident occurred), but the in- 
terface does not provide a calendar widget so that the user can easily select 
the date. This deficiency in the user interface may increase the chances that 
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the user enters the wrong date. In other words, this deficiency contributes to 
the issue “Incorrect claim data entry”. 

While the distinction between causal and contributing factor is generally 
useful when investigating specific incidents (for example investigating the 
causes of a given road accident), the distinction is often not relevant or not 
sufficiently sharp in the context of business process analysis. Accordingly, in 
this chapter we will use the term factor to refer to causal and contributing 
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factors collectively. 


In a cause-effect diagram, factors are grouped into categories and possibly also 
sub-categories. These categories are useful in order to guide the search for causes. 
For example, when organizing a brainstorming session for root cause analysis, one 
way to structure the session is to first go around the table asking each participant 
to give their opinion on possible causes of the issue at hand. The causes are first 
written down in any order. Next, the identified causes are classified according to 
certain categories and the discussion continues in a more structured way using these 
categories as a framework. 

A well-known categorization for cause-effect analysis are the so-called 6M’s, 
which are described below together with possible sub-categorizations. 


1. Machine (technology)—factors pertaining to the technology used, like for ex- 
ample software failures, network failures or system crashes that may occur in the 
information systems that support a business process. A useful sub-categorization 
of Machine factors is the following: 


a. 
b. 


Lack of functionality in application systems. 

Redundant storage of data across systems, leading for example to double data 
entry (same data entered twice in different systems) and data inconsistencies 
across systems. 

Low performance of IT of network systems, leading for example to low re- 
sponse times for customers and process participants. 


. Poor user interface design, leading for example to customers or process partic- 


ipants not realizing that some data are missing or that some data are provided 
but not easily visible. 

Lack of integration between multiple systems within the enterprise or with 
external systems such as a supplier’s information system or a customer’s in- 
formation system. 


2. Method (process)—factors stemming from the way the process is defined or 
understood or in the way it is performed. An example of this is when a given 
process participant A thinks that another participant B will send an e-mail to a 
customer, but participant B does not send it because they are not aware they have 
to send it. Possible sub-categories of Method factors include: 


a. 


Unclear, unsuitable or inconsistent assignment of decision-making and pro- 
cessing responsibilities to process participants. 
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b. Lack of empowerment of process participants, leading to process participants 
not being able to make necessary decisions without consulting several lev- 
els above in their organizational hierarchy. Conversely, excessive empower- 
ment may lead to process participants having too much discretion and causing 
losses to the business through their actions. 

c. Lack of timely communication between process participants or between pro- 
cess participants and the customer. 

3. Material—factors stemming from the raw materials, consumables or data re- 
quired as input by the activities in the process, like for example incorrect data 
leading to a wrong decision being made during the execution of a process. The 
distinction between raw materials, consumables and data provides a possible sub- 
categorization of these factors. 

4. Man—factors related to a wrong assessment or an incorrectly performed step, 
like for example a claims handler accepting a claim even though the data in the 
claim and the rules used for assessing the claim require that the claim be rejected. 
Possible sub-categories of Man factors include: 

a. Lack of training and clear instructions for process participants. 

b. Lack of incentive system to motivate process participants sufficiently. 

c. Expecting too much from process participants (e.g. overly hectic schedules). 

d. Inadequate recruitment of process participants. 

5. Measurement—factors related to measurements or calculations made during the 
process. In the context of an insurance claim, an example of such a factor is one 
where the amount to be paid to the customer is miscalculated due to an inaccurate 
estimation of the damages being claimed. 

6. Milieu—factors stemming from the environment in which the process is exe- 
cuted, like for example factors originating from the customer, suppliers or other 
external actors. Here, the originating actor is a possible sub-categorization. Gen- 
erally, milieu factors are outside the control of the process participants, the pro- 
cess owner, and other company managers. For example, consider a process for 
handling insurance claims for car accidents. This process depends partly on data 
extracted from police reports (e.g. police reports produced when a major accident 
occurs). It may happen in this context that some errors during the claims handling 
process originate from inaccuracies or missing details in the police reports. These 
factors are to some extent outside the control of the insurance company. This ex- 
ample illustrates that milieu factors may need to be treated differently from other 
(internal) factors. 


These categories are meant as guidelines for brainstorming during root cause 
analysis rather than gospel that should be followed to the letter. Other ways of cate- 
gorizing factors may be equally useful. For example, one alternative categorization 
is known as the 4P’s (Policies, Procedures, People, and Plant/Equipment). Also, 
it is sometimes useful to classify factors according to the activities in the process 
where they originate (i.e. one category per major activity in the process). This ap- 
proach allows us to easily trace the relation between factors and activities in the 
process. 
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Causal Factors Issue 


Measurement 


Primary Primary Primary 


Fig. 6.1 Template of a cause-effect diagram based on the 6M’s 


The above categories are useful not only as a guide for brainstorming during root 
cause analysis, but also as a basis for documenting the root causes in the form of a 
cause-effect diagram. Concretely, a cause-effect diagram consists of a main hori- 
zontal line (the trunk) from which a number of branches stem (cf. Fig. 6.1). At one 
end of the trunk is a box containing the negative effect that is being analyzed (in 
our case the issue being analyzed). The trunk has a number of main branches cor- 
responding to the categories of factors (e.g. the 6M’s above). The root causes are 
written in the sub-branches. Sometimes, it is relevant to distinguish between pri- 
mary factors, meaning factors that have a direct impact on the issue at hand, from 
secondary factors, which are factors that have an impact on the primary factors. 
For example, in the context of an insurance claims handling process, an inaccurate 
estimation of the damages leads to a miscalculation of the amount to be paid for 
a given claim. This inaccurate estimation of the damages may itself stem from a 
lack of incentive from the repairer to accurately calculate the cost of repairs. Thus, 
“Inaccurate damage estimation” can be seen as a primary factor for “Liability mis- 
calculation”, while “Lack of incentive to calculate repair costs accurately” is a sec- 
ondary factor behind the “Inaccurate damage estimation”. The distinction between 
primary and secondary factors is a first step towards identifying chains of factors 
behind an issue. We will see later in this chapter that why—why diagrams allow us 
to dig deeper into such chains of factors. 

Because of their visual appearance, cause-effect diagrams are also known as 
Fishbone diagrams. Another common name for such diagrams is [shikawa diagrams 
in allusion to one of its proponents—Kaoru Ishikawa—one of the pioneers of the 
field of quality management. 
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Causal Factors Issue 


Measurement 


Clerk 
selected equipment 
with incorrect specs 


Inaccurate 
equipment description in 
provider's catalogue 


Equipment 


rejected at 
delivery 


Clerk is entirely responsible 


Incomplete or inaccurate 2. i 
for equipment selection 


requirements from site engineer, 


Clerk 
misunderstood 
site engineer's requirement, 


Site engineer does not 
know what equipment will be rgnted 


Fig. 6.2 Cause-effect diagram for issue “Equipment rejected at delivery” 


Example 6.2 We consider again the equipment rental process described in Exam- 
ple 1.1 (p. 2). During an audit of this process, several issues were identified. It turns 
out that oftentimes the site engineer finds that the equipment delivered at the con- 
struction site is not suitable because it is either too small or not powerful enough 
for the job. Hence it has to be rejected. One clerk claims that the site engineers 
generally do not specify their requirements in sufficient detail. Other clerks blame 
the suppliers for giving inaccurate or incomplete descriptions of their equipment in 
their catalogs. On the other hand, site engineers complain that they are not consulted 
when there are doubts regarding the choice of equipment. 

This scenario basically describes one issue, namely that the equipment is being 
rejected upon delivery. We can see three primary causes from the issue, which are 
summarized in the cause-effect diagram in Fig. 6.2. The diagram also shows sec- 
ondary causes underpinning each of the primary causes. Note that the factor “clerk 
selected equipment with incorrect specs” has been classified under the Material cat- 
egory because this factor stems from incorrect input data. A defect in input data 
used by a process falls under the Material category. 


Exercise 6.2 Consider the university admission process described in Exercise 1.1 
(p. 4). One of the issues faced by the university is that students have to wait too 
long to know the outcome of the application (especially for successful outcomes). It 
often happens that by the time a student is admitted, the student has decided to go to 
another university instead (students send multiple applications in parallel to many 
universities). Analyze the causes of this issue using a cause-effect diagram. 
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6.2.2, Why—Why Diagrams 


Why-why diagrams (also known as tree diagrams) constitute another technique to 
analyze the cause of negative effects, such as issues in a business process. The em- 
phasis of root cause analysis is to capture the series of cause-to-effect relations that 
lead to a given effect. The basic idea is to recursively ask the question: Why has 
something happened? This question is asked multiple times until a factor that stake- 
holders perceive to be a root cause is found. A common belief in the field of quality 
management—known as the five Why’s principle—has it that answering the “why” 
question five times recursively allows one to pin down the root causes of a given 
negative effect. Of course, this should not be treated as gospel, but as a guideline of 
how far one should go during root cause analysis. 

Why-why diagrams are a technique for structuring brainstorming sessions (e.g. 
workshops) for root cause analysis. Such a session would start with an issue. The 
first step is to give a name to the issue that stakeholders agree on. Sometimes it is 
found that there is not one issue, but multiple issues, in which case they should be 
analyzed separately. Once the issue has been identified and a name has been agreed 
upon, this becomes the root of the tree. Then at each level the following questions 
are asked: “Why does this happen?” and “What are the main sub-issues that may 
lead to this issue?”. Possible factors are then identified. Each of these factors is 
then analyzed using the same questions. When getting down in the tree (e.g. to 
levels 3 or 4) it is recommended to start focusing on factors that can be resolved, 
meaning that something can be done to change them. The leaves of the tree should 
correspond to factors that are fundamental in nature, meaning that they cannot be 
explained in terms of other factors. Ideally, these factors, called root causes, should 
be such that they can be eliminated or mitigated, but this is not necessarily the case. 
For example, in the context of an insurance claims handling process, a certain type 
of errors in a police report may be due to lack of time and hectic schedules on the 
side of police agents involved in filling these reports. There is relatively little the 
insurance agency can do in this case to eliminate the error, other than raising the 
issue with the relevant authorities. Yet, the impact of this factor could be mitigated 
by putting in place checks to detect such errors as early as possible in the process. 

A simple template for why—why diagrams is given in Fig. 6.3. An alternative way 
of presenting the information in such diagrams is by means of nested bullet-point 
lists. In the rest of this chapter we will opt for the latter representation. 


Example 6.3 We consider again the equipment rental process described in Exam- 
ple 1.1 (p. 2). In Example 6.2 above, we noted that one of the issues with this process 
is that the site engineer sometimes rejected the equipment upon delivery because it 
was not suitable for the job at hand. Another issue is that BuildIT spends more in 
equipment rental than what it budgeted for. An auditor pointed out that one of the 
reasons for excessive expenditure was that site engineers were keeping the rented 
equipment longer than initially planned by using deadline extensions. Site engineers 
knew that it was easy to get a deadline extension. They also knew that it took quite 
some time to get equipment rental requests approved, and the larger the cost and 
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why-—why diagram 
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the duration of the rental, the slower it was to get it approved. So in many cases, 
site engineers were renting equipment several days before the date when they ac- 
tually needed it. Also, they were specifying short periods in their equipment rental 
requests in order to get them approved quicker. When the deadline for returning 
an equipment approached, they just called the supplier to keep the equipment for a 
longer period. 

Another issue spotted by the auditor is that a significant amount of late-payment 
penalty fees were paid to the suppliers because invoices for equipment rental were 
not paid by their due date. The clerks blamed the site engineers for being slow in 
approving the invoices. 

In summary, we can distinguish at least three issues. First, the wrong equipment 
is being delivered on some occasions. Secondly site engineers are frequently asking 
for deadline extensions. Thirdly, BuildIT is often paying late payment fees to sup- 
pliers. A possible analysis root cause analysis of these issues leads to the following 
why—why diagrams (represented as nested bullet-point lists). 


Issue 1 Site engineers sometimes reject delivered equipment, why? 
Wrong equipment is delivered, why? 


— miscommunication between site engineer and clerk, why? 
e site engineer provides only brief/inaccurate description of what they want 
e site engineer does not (always) see the supplier catalogs when making a request 
and does not communicate with the supplier, why? 
- site engineer generally does not have Internet connectivity 
e site engineer does not check the choice of equipment made by the clerk 
— equipment descriptions in supplier’s catalog not accurate 


Issue 2 Site engineers keep equipment longer than needed via deadline extensions, 
why? 


Site engineer fears that equipment will not be available later when needed, why? 
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— time between request and delivery too long, why? 
e excessive time spent in finding a suitable equipment and approving the request, 
why? 
- time spent by clerk contacting possibly multiple suppliers sequentially 
- time spent waiting for works engineer to check the requests 


Issue 3 BuildIT often has to pay late payment fees to suppliers, why? 
Time between invoice received by clerk and confirmation is too long, why? 


— clerk needs confirmation from site engineer, why? 

e clerk cannot assert when was the equipment delivered and picked-up, why? 
- delivery and pick-up of equipments are not recorded in a shared informa- 
tion system 
- site engineer can extend the equipment rental period without informing the 
clerk 

e site engineer takes too long to confirm the invoice, why? 
confirming invoices is not a priority for site engineer 


Exercise 6.3 Consider again the process for university admission described in Ex- 
ercise 1.1 (p. 4) and the issue described in Exercise 6.2 above. Analyze this issue 
using a why—why diagram. 


6.3 Issue Documentation and Impact Assessment 


Root cause analysis techniques allow us to understand the factors behind a given 
issue. A natural next step is to understand the impact of these issues. Building up 
this understanding is critical in order to prioritize the issues so that the attention of 
the process owner, participants and analysts can be focused on the issues that most 
matter to the organization. Below we discuss two complementary techniques for 
impact assessment. 


6.3.1 Issue Register 


The issue register complements the output of root cause analysis by providing a 
more detailed analysis of individual issues and their impact. The purpose of the is- 
sue register is to determine how and to what extent each issue is impacting on the 
performance of the process. The impact of an issue can be described quantitatively, 
for example in terms of time or money lost, or qualitatively, in terms of perceived 
nuisance to the customer or perceived risks that the issue entails. For example, nui- 
sances caused to the customer because of misunderstandings during the execution 
of the process can be classified as qualitative impact, since it is difficult to translate 
this nuisance into a monetary measure. 
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Concretely, an issue register is a listing that provides a detailed analysis of each 
issue and its impact in the form of a table with a pre-defined set of fields. The 
following fields are typically described for each issue: 


e Name of the issue. This name should be kept short, typically two—five words, and 
should be understandable by all stakeholders in the process. 

e Description. A short description of the issue, typically one-three sentences, fo- 
cused on the issue itself as opposed to its consequences or impact, which are 
described separately. 

e Priority. A number (1, 2,3,...) stating how important this issue is relative to 
other issues. Note that multiple issues can have the same priority number. 

e Assumptions (or input data). Any data used or assumptions made in the estimation 
of the impact of the issue, such as for example number of times a given negative 
outcome occurs, or estimated loss per occurrence of a negative outcome. In the 
early phases of the development of the issue register, the numbers in this column 
will be mainly assumptions or ballpark estimates. Over time, these assumptions 
and rough estimates will be replaced with more reliable numbers derived from 
actual data about the execution of the process. 

e Qualitative impact. A description of the impact of the issue in qualitative terms, 
such as impact of the issue on customer satisfaction, employee satisfaction, long- 
term supplier relationships, company’s reputation or other intangible impact that 
is difficult to quantify. 

e Quantitative impact. An estimate of the impact of the issue in quantitative terms, 
such as time loss, revenue loss or avoidable costs. 


Other fields may be added to an issue register. For example, in view of process 
redesign, it may be useful to include an attribute possible resolution that describes 
possible mechanisms for addressing the issue. 


Example 6.4 We consider again the equipment rental process described in Exam- 
ple 1.1 (p. 2) and the issues described above in Examples 6.2 and 6.3. The issue 
register given in Table 6.2 provides a more detailed analysis of these issues and 
their impact.! 


Question Issue or factor? 


An issue register is likely to contain a mixture of issues that have a direct impact 
on business performance, and others that are essentially causal or contributing fac- 
tors of other issues that then impact on business performance. In other words, the 
issue register contains both issues and factors. For example, in the issue register of 
the equipment rental process, one could find the following entries: 


e Clerk misunderstood the site engineer’s requirements for an equipment. 


'In this issue register we do not use multiple columns. This is a pragmatic choice to better fit the 
issue register within the width of the page. 
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Table 6.2 Issue register of equipment rental process 


Issue 1: Equipment kept longer than needed 

Priority: 1 

Description: Site engineers keep the equipment longer than needed by means of deadline 
extensions 


Assumptions: BuildIT rents 3000 pieces of equipment per year. In 10 % of cases, site engineers 
keep the equipment two days longer than needed to avoid disruptions due to delays in equipment 
rentals. On average, rented equipment costs € 100 per day 


Qualitative impact: Not applicable 
Quantitative impact: 0.1 x 3000 x 2 x € 100 = € 60,000 in additional rental expenses per year 


Issue 2: Rejected equipment 

Priority: 2 

Description: Site engineers sometimes reject the delivered equipment due to non-conformance to 
their specifications 


Assumptions: BuildIT rents 3000 pieces of equipment per year. Each time an equipment is 
rejected due to a mistake on BuildIT’s side, BuildIT is billed the cost of one day of rental, that is 
€ 100. 5 % of them are rejected due to an internal mistake within BuildIT (as opposed to a 
supplier mistake) 


Qualitative impact: These events disrupt the construction schedules and create frustration and 
internal conflicts 


Quantitative impact: 3000 x 0.05 x € 100 = € 15,000 per year 


Issue 3: Late payment fees 
Priority: 3 
Description: BuildIT pays late payment fees because invoices are not paid by the due date 


Assumptions: BuildIT rents 3000 pieces of equipment per year. Each equipment is rented on 
average for 4 days at a rate of € 100 per day. Each rental leads to one invoice. About 10 % of 
invoices are paid late. On average, the penalty for late payment is 2 % of the amount of the invoice 
Qualitative impact: Suppliers are annoyed and later unwilling to negotiate more favorable terms 
for equipment rental 


Quantitative impact: 0.1 x 3000 x 4 x € 100 x 0.02 = € 2400 per year 


e Clerk did not select the correct equipment from the supplier’s catalog due to inat- 
tention. 

e Clerk indicated an incorrect delivery date in the PO and the supplier used this 
wrong date. 

e Supplier did not deliver the exact equipment that had been ordered. 

e Delivered equipment is faulty or is not ready-for-use. 

e Supplier delivered the equipment to the wrong construction site or at the wrong 
time. 


All of the above issues are possible causal or contributing factors of a top-level 
issue, namely “Equipment is rejected by the site engineer”. The fact that the site 
engineer rejects the equipment creates a direct impact for BuildIT, for example in 
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terms of delays in the construction schedule. Meanwhile, the issues listed above 
have an indirect business impact, in the sense that they lead to the equipment being 
rejected and the needed equipment not being available on time, which in turn leads 
to delays in the construction schedule. 

When an issue register contains a combination of issues and factors, it may be 
useful to add two fields to the register, namely “caused by” and “is cause of”, that 
indicate for a given issue, which other issues in the register are related to it via a 
cause-effect relation. This way it becomes easier to identify which issues are related 
between them so that related issues can be analyzed together. Also, when an issue 
X is a factor of an issue Y, instead of analyzing both the impact of X and Y, we can 
analyze the impact of Y and in the qualitative and quantitative impact fields of X we 
can simply refer to the impact of Y. For example, in the impact field of issue “Clerk 
misunderstood the site engineer’s requirements” we can simply refer to the impact 
of “Equipment is rejected by the site engineer’. 

Alternatively, we can adopt the convention of including in the issue register only 
top-level issues, meaning issues that have a direct business impact, and separately, 
we can use why—why diagrams and cause-effect diagrams to document the factors 
underpinning these top-level issues. This convention is followed in the rest of this 
chapter, meaning that the issue registers shown below only contain top-level issues 
rather than factors. 


Exercise 6.4 Write an issue register for the university admission process and the 
issue described in Exercise 6.2. 


6.3.2 Pareto Analysis and PICK Charts 


The impact assessment conducted while building the issue register can serve as 
input for Pareto analysis. The aim of Pareto analysis is to identify which issues 
or which causal factors of an issue should be given priority. Pareto analysis rests on 
the principle that a small number of factors are responsible for the largest share of a 
given effect. In other words: 


e A small subset of issues in the issue register are likely responsible for the largest 
share of impact. 

e For a given issue, a small subset of factors behind this issue are likely responsible 
for the largest share of occurrences of this issue. 


Sometimes this principle is also called the 80—20 principle, meaning that 20 % 
of issues are responsible for 80 % of the effect. One should keep in mind, however, 
that the specific proportions are only indicative. It may be for example that 30 % of 
issues are responsible for 70 % of the effect. 

A typical approach to conduct Pareto analysis is as follows: 


1. Define the effect to be analyzed and the measure via which this effect will be 
quantified. The measure might be for example: 
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Fig. 6.4 Pareto chart for excessive equipment rental expenditure 


e Financial loss for the customer or for the business. 

e Time loss by the customer or by the process participants. 

e Number of occurrences of a negative outcome, such as number of unsatisfied 
customers due to errors made when handling their case. 


2. Identify all relevant issues that contribute to the effect to be analyzed. 

3. Quantify each issue according to the chosen measure. This step can be done on 
the basis of the issue register, in particular, the quantitative impact column of the 
register. 

4. Sort the issues according to the chosen measure (from highest to lowest impact) 
and draw a so-called Pareto chart. A Pareto chart consists of two components: 
a. A bar chart where each bar corresponds to an issue and the height of the bar 

is proportional to the impact of the issue or factor. 

b. A curve that plots the cumulative percentage impact of the issues. For exam- 
ple, if the issue with the highest impact is responsible for 40 % of the impact, 
this curve will have a point with a y-coordinate of 0.4 and an x-coordinate 
positioned so as to coincide with the first bar in the bar chart. 


Example 6.5 Consider again the equipment rental process described in Example 1.1 
(p. 2) and the issue register in Example 6.4. All three issues in this register share in 
common that they are responsible for unnecessary rental expenditure, which is a 
form of financial loss. From the data in the impact column of the register, we can 
plot the Pareto chart in Fig. 6.4. 

This Pareto chart shows that issue “Slow rental approval” is responsible already 
for 63 % of unnecessary rental expenditure. Given that in this example there are only 
three issues, one could have come to this conclusion without conducting Pareto anal- 
ysis. In practice though, an issue register may contain dozens or hundreds of issues, 
making Pareto analysis a useful tool to summarize the data in the issue register. 
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Exercise 6.5 Let us consider again the equipment rental process. This time we take 
the perspective of the site engineer, whose goal is to have the required equipment 
available on site when needed. From this perspective, the main issue is that in about 
10 % of cases, the requested equipment is not available on site the day when it 
is required. When this happens, the site engineer contacts the suppliers directly to 
resolve the issue, but still, resolving the issue may take several days. It is estimated 
that each such delay costs € 400 per day to BuildIT. By inspecting a random sample 
of delayed equipment deliveries during a one-year period and investigating the cause 
of each occurrence, an analyst found that: 


1. five occurrences were due to the site engineer not having ordered the equipment 
with sufficient advance notice: The site engineers ordered the equipment the day 
before it was needed, when at least two days are needed. These cases cause delays 
of one day on average. 

2. nine occurrences were due to the fact that none of BuiltIT’s suppliers had the 
required type of equipment available on the requested day. These cases cause 
delays of one to four days (three days on average). 

3. 13 occurrences were due to the approval process taking too long (more than a 
day) due to mistakes or misunderstandings. For these cases, the delay was one 
day on average. 

4. 27 occurrences were due to the equipment having been delivered on time, but the 
equipment was not suitable and the site engineer rejected it. These cases cause 
delays of two days on average. 

5. four occurrences were due to mistakes or delays attributable entirely to the sup- 
plier. These cases lead to delays of one day. However, in these cases, the supplier 
compensated BuildIT by providing the equipment two days for free (the remain- 
ing days are still charged). Recall that the average cost of an equipment rental 
per day is € 100. 

6. For two occurrences, the analyst did not manage to determine the cause of the 
delay (the process participants could not recall the details). The delays in these 
cases where two days per occurrence. 


The sample of analyzed occurrences represents around 20 % of all occurrences 
of the issue during a one-year period. 
Draw a Pareto chart corresponding to the above data. 


It is worth highlighting that Pareto analysis focuses on a single dimension. In the 
example above, the dimension under analysis is the impact in monetary terms. In 
other words, we focus on the estimated payoff of addressing an issue. In addition to 
payoff, there is another dimension that should be taken into account when deciding 
which issues should be given higher priority, namely the level of difficulty of ad- 
dressing an issue. This level of difficulty can be quantified in terms of the amount of 
investment required to change the process in order to address the issue in question. 

A type of chart that can be used as a complement to Pareto charts in order to take 
into account the difficulty dimension is the PICK chart. A PICK chart (see Fig. 6.5) 
is a four-quadrant chart where each issue appears as a point. The horizontal axis 
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captures the difficulty of addressing the issue (or more specifically the difficulty of 
implementing a given improvement idea that addresses the issue) while the vertical 
axis captures the payoff. The horizontal axis (difficulty) is split into two sections 
(easy and hard) while the vertical axis (payoff) is split into low and high. These 
splits lead to four quadrants that allow analysts to classify issues according to the 
trade-off between payoff and difficulty: 


e Possible (low payoff, easy to do): issues that can be addressed if there are suffi- 
cient resources for doing so. 

e Implement (high payoff, easy to do): issues that should definitely be implemented 
as a matter of priority. 

e Challenge (high payoff, hard to do): issues that should be addressed but require 
significant amount of effort. In general one would pick one of these challenges 
and focus on it rather than addressing all or multiple challenges at once. 

e Kill (low payoff, hard to do): issues that are probably not worth addressing or at 
least not to their full extent. 


6.4 Recap 


In this chapter, we presented a selection of techniques for qualitative analysis of 
business processes. The first presented technique, namely value-added analysis, 
aims at identifying waste, specifically time wasted in activities that do not give value 
to the customer or to the business. Next, we presented two techniques to uncover the 
causes of issues that affect the performance of a process, namely cause-effect anal- 
ysis and why—why analysis. Whereas cause-effect analysis focuses on classifying 
the factors underpinning the occurrences of an issue, why—why analysis focuses on 
identifying the recursive cause-effect relations between these factors. 

Finally, we presented an approach to systematically document issues in a process, 
namely the issue register. The purpose of an issue register is to document issues 
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in a semi-structured way and to analyze their impact on the business both from 
a qualitative and a quantitative angle. In particular, the issue register provides a 
starting point to build Pareto charts and PICK charts—two visualization techniques 
that provide a bird’s-eye view of a set of issues. These charts help analysts to focus 
their attention on issues that offer the best payoff (in the case of Pareto charts) or 
the best trade-off between payoff and difficulty (in the case of PICK charts). 


6.5 Solutions to Exercises 


Solution 6.1 


e VA: receive online application, evaluate academic admissibility, send notification 
to student. 

e BVA: check completeness, academic recognition agency check, English test 
check. 

e NVA: receive physical documents from students, forward documents to commit- 
tee, notify students service of outcomes of academic admissibility. 


Note In this solution we treat the entire agency check as BVA. Part of this agency 
check consists of the admissions office sending the documents to the agency and 
the agency sending back the documents and their assessment to the admissions of- 
fice. These two sub-steps could be treated as NVA. However, if we assume that the 
agency requires the documents to be sent by post to them, these sub-steps cannot be 
easily separated from the agency check itself. In other words, it would not be pos- 
sible to eliminate these handover steps without eliminating the entire agency check. 
Thus the entire agency check should arguably be treated as a single step. 


Solution 6.2 The cause-effect diagram corresponding to this exercise should in- 
clude at least the name of the issue (e.g. “Student waiting time too long’’) and the 
following factors: 


e Process stalls due to agency check. This is a “Method” issue, since the issue 
stems from the fact that the process essentially stalls until a response is received 
from the agency. One could argue that to some extent this is a “Milieu” issue. 
But while the slowness of the agency check is a “Milieu” issue, the fact that the 
process stalls until a response is received from the agency is a “Method” issue. 

e Agency check takes too long. This is a “Milieu” issue since the agency is a sepa- 
rate entity that imposes its own limitations. 

e Academic committee assessment takes too long. This is a “Method” issue since 
the process imposes that the academic committee only assesses applications at 
certain times (when it meets), rather than when applications are ready to be eval- 
uated. 

e Physical documents take too long to be received. This is a “Milieu” issue for two 
reasons. First, the physical documents are needed for the purpose of the agency 
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check and the delays in the arrival of physical documents are caused by the ap- 
plicants themselves and postal service delays. 

e Admission office delays the notification after academic assessment. This seems 
to be a “Method” issue, but the description of the process does not give us suffi- 
cient information to state this conclusively. Here, a process analyst would need to 
gather more information in order to understand this issue in further detail. 


Solution 6.3 
Admission process takes too long, why? 


— Process stalls until physical documents arrive, why? 
e Agency check requires physical documents. 
e Other tasks are performed only after agency check, why? 
- Traditionally this is how the process is set-up but there is no strong reason 
for it. 
— Agency check takes too long, why? 
e Exchanges with the agency are via post, why? 
- Agency requires original (or certified) documents due to regulatory require- 
ments. 


Academic committee takes too long, why? 


— Documents are exchanged by internal mail between admissions office and com- 
mittee. 
— Academic committee only meets at specified times. 


Admission office delays the notification after academic assessment, why? 


— Not enough information available to analyze this issue (probably due to batching 
—admissions office sends notifications in batches). 


The above analysis already suggests one obvious improvement idea: perform the 
academic committee assessment in parallel to the agency check. Another improve- 
ment opportunity is to replace internal mail communication between admissions of- 
fice and academic committee with electronic communication (e.g. documents made 
available to committee members via a Web application). 

Note that we could have done the analysis starting from the issue “Admitted stu- 
dents reject their admission offer”. This might be useful since there might be several 
reasons why students reject their offer, some related to the admission process, but 
also some unrelated to the process. 


Solution 6.4 In the following issue register, we only analyze the issue described in 
this chapter, namely that the admission process takes too long. In practice, the issue 
register would include multiple issues. 
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Issue 1: Students reject offer due to long waiting times 

Priority: 1 

Description: The time between online submission of an application to notification 
of acceptance takes too long, resulting in some students rejecting their admission 
offer 

Assumptions: Circa 20 students per admission round reject their offer because of 
the delays. Assessment of each application costs € 100 per student to the 
university in time spent by admissions office and academic committee, plus an 
additional € 50 for the agency check. University spends € 100 in marketing for 
each application it attracts 

Qualitative impact: Students who would contribute to the institution in a positive 
way are lost. Delays in the admission process affect the image of the university 
vis-a-vis of future students, and generate additional effort to handle enquiries from 
students while they wait for the admission decisions 

Quantitative impact: 20 x € 250 = € 5000 per admission round 


In the above issue analysis, the effort required to deal with enquiries during the 
pre-admission period is listed in the qualitative impact field. If it was possible (with 
a reasonable amount of effort) to estimate how many such enquiries arrive and how 
much time they consume, it would be possible to turn this qualitative impact into a 
quantitative one. 


Solution 6.5 First, we analyze the cost incurred by each type of occurrence (i.e. 
each causal factor) in the sample: 


1. Last-minute request: one day delay (because normally two days advance notice 
are needed), thus € 400 cost x 5 = € 2000. 

2. Equipment out-of-stock: three days delay = € 1200 x 9 = € 10,800. 

. Approval delay: one day delay = € 400 x 13 = € 5200. 

4. Rejected equipment: two days delay = € 800 x 27 = € 21,600. Note that in Ex- 
ample 6.4 we mentioned that when an equipment is rejected, a fee of € 100 (on 
average) has to be paid to the supplier for taking back the equipment. However, 
we do not include this fee here because we are interested in analyzing the costs 
stemming from equipment not being available on the required day, as opposed to 
other costs incurred by rejecting equipments. 

5. Supplier mistake: one day delay = € 400 minus € 200 in rental cost saving = 
€ 200 x 4= € 800. 

6. Undetermined: two days delay = € 800 x 2 = € 1600. 


io) 


Since the sample represents 20 % of occurrences of the issue over a year, we mul- 
tiply the above numbers by five in order to estimate the total yearly loss attributable 
to each causal factor. The resulting Pareto chart is given in Fig. 6.6. 


208 6 Qualitative Process Analysis 


108000 108000 100% 


90% 
80% 
70% 
60% 
50% 
40% 
30% 


20% 


10% 


Fig. 6.6 Pareto chart of causal factors of issue “Equipment not available when needed” 


6.6 Further Exercises 


Exercise 6.6 Consider the following summary of issues reported in a travel agency. 


A travel agency has recently lost several medium-sized and large corporate customers due 
to complaints about poor customer service. The management team of the travel agency 
decided to appoint a team of analysts to address this problem. The team gathered data by 
conducting interviews and surveys with current and past corporate customers and also by 
gathering customer feedback data that the travel agency has recorded over time. About 2 % 
of customers complained about errors that had been made in their bookings. In one occasion, 
a customer had requested a change to a flight booking. The travel agent wrote an e-mail to 
the customer suggesting that the change had been made and attached a modified travel 
itinerary. However, it later turned out that the modified booking had not been confirmed in 
the flight reservation system. As a result, the customer was not allowed to board the flight 
and this led to a series of severe inconveniences for the customer. Similar problems had 
occurred when booking a flight initially: the customer had asked for certain dates, but the 
flight tickets had been issued for different dates. Additionally, customers complained of the 
long times it took to get responses to their requests for quotes and itineraries. In most cases, 
employees of the travel agency replied to requests for quotes within 2-4 working hours, but 
in the case of some complicated itinerary requests (about 10 % of the requests), it took them 
up to 2 days. Finally, about 5 % of customers also complained that the travel agents did not 
find the best flight connections and prices for them. These customers essentially stated that 
they had found better itineraries and prices on the Web by searching by themselves. 


1. Analyze the issues described above using root cause analysis techniques. 

2. Document the issues in the form of an issue register. To this end, you may assume 
that the travel agency receives around 100 itinerary requests per day and that the 
agency makes 50 bookings per day. Each booking brings a gross profit of € 100 
to the agency. 
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Exercise 6.7 Consider the pharmacy prescription fulfillment process described in 
Exercise 1.6 (p. 28). Identify the steps in this process and classify them into value- 
adding, business value-adding and non-value-adding. 


Exercise 6.8 Consider the procure-to-pay process described in Exercise 1.7 (p. 29). 
Identify the steps in this process and classify them into value-adding, business value- 
adding and non-value-adding. 


Exercise 6.9 Write an issue register for the pharmacy prescription fulfillment pro- 
cess described in Exercise 1.6 (p. 28). Analyze at least the following issues: 


e Sometimes, a prescription cannot be filled because one or more drugs in the pre- 
scription are not in stock. The customer only learns this when they come to pick 
up their prescription. 

e Oftentimes, when the customer arrives to pick up the drugs, they find out that they 
have to pay more than what they expected because their insurance policy does not 
cover the drugs in the prescription, or because the insurance company covers only 
a small percentage of the cost of the drugs. 

e Ina very small number of cases, the prescription cannot be filled because there is 
a potentially dangerous interaction between one of the drugs in the prescription 
and other drugs that the customer has been given in the past. The customer only 
finds out about this issue when they arrive to pick up the prescription. 

e Some prescriptions can be filled multiple times. This is call a “refill”. Every pre- 
scription explicitly states whether a refill is allowed and if so how many refills 
are allowed. Sometimes, a prescription cannot be filled because the number of 
allowed refills has been reached. The pharmacist then tries to call the doctor who 
issued the prescription to check if the doctor would allow an additional refill. 
Sometimes, however, the doctor is unreachable or the doctor does not authorize 
the refill. The prescription is then left unfilled and the customer only finds it out 
when they arrive to pick-up the prescription. 

e Oftentimes, especially during peak time, customers have to wait for more than 10 
minutes to pick-up their prescription due to queues. Customers find this annoying 
because they find that having to come twice to the pharmacy (once for drop-off 
and once for pick-up) should allow the pharmacy ample time to avoid such queues 
at pick-up. 

e Sometimes, the customer arrives at the scheduled time, but the prescription is not 
yet filled due to delays in the prescription fulfillment process. 


When making assumptions to analyze these issues, you may choose to equate 
“oftentimes” with “20 % of prescriptions”, “sometimes” with “5 % of prescriptions” 
and “very small number of cases” with “1 % of prescriptions”. You may also assume 
that the entire chain of pharmacies consists of 200 pharmacies that serve 4 million 
prescriptions a year and that the annual revenue of the pharmacy chain attributable 
to prescriptions is € 200 million. You may also assume that every time a customer 


is dissatisfied when picking up a prescription, the probability that this customer will 
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not come back after this experience is 20 %. You may also assume that on average 
a customer requires five prescriptions per year. 

Taking the issue register as a basis, apply Pareto Analysis to determine a subset of 
issues that should be addressed to reduce the customer churn due to dissatisfaction 
by at least 70 %. Customer churn is the number of customers who stop consuming 
services offered by a company at a given point in time. In this context, this means 
the number of customers who stop coming to the pharmacy due to a bad customer 
experience. 


Exercise 6.10 Write an issue register for the procure-to-pay process described in 
Exercise 1.7 (p. 29). 


6.7 Further Reading 


Value-added analysis, cause-effect analysis, why—why analysis and Pareto analy- 
sis are just a handful of a much wider range of techniques used in the field of 
Six Sigma (cf. “Related Fields” box in Chap. 1). Conger [8] shows how these 
and other Six Sigma techniques can be applied for business process analysis. The 
list of analysis techniques encompassed by Six Sigma is very extensive. A com- 
prehensive listing of Six Sigma techniques is maintained in the iSixSigma por- 
tal (http://www.isixsigma.com/tools-templates/). A given business process improve- 
ment project will generally only make use of a subset of these techniques. In this 
respect, Johannsen et al. [38] provide guidelines for selecting analysis techniques 
for a given BPM project. 

Straker’s Quality Encyclopedia (see http://www.syque.com/improvement/a_ 
encyclopedia.htm) provides a comprehensive compendium of concepts used in Six 
Sigma and other quality management disciplines. In particular, it provides defi- 
nitions and illustrations of the 6M’s and the 4P’s used in cause-effect diagrams 
and other concepts related to root cause analysis. A related resource—also by 
Straker—is the Quality Toolbook, which summarizes a number of quality man- 
agement techniques. Originally the Quality Toolbook was published as a hard- 
copy book [89], but it is nowadays also available freely in hyperlinked form at: 
http://www.syque.com/quality_tools/toolbook/toolbook.htm. 

Why-why diagrams allow us to document sequences of cause-effect relations 
that link factors to a given issue. A related technique to capture cause-effect paths is 
the causal factor chart [77]. Causal factor charts are similar to why—why diagrams. 
A key difference is that in addition to capturing factors, causal factor charts also 
capture conditions surrounding the factors. For example, in addition to stating that 
“the clerk made a data entry mistake when creating the PO”, a casual factor chart 
might also include a condition corresponding to the question “in which part of the 
PO the clerk made a mistake?” These additional conditions allow analysts to more 
clearly define each factor. 
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The issue register has been proposed as a process analysis tool by Schwegmann 
and Laske [84]* who use the longer term “list of weaknesses and potential improve- 
ments” to refer to an issue register. Schwegmann and Laske argue that the issue 
register should be built up in parallel with the as-is model, meaning that the discov- 
ery of the as-is process and the documentation of issues should go hand in hand. 
The rationale is that during the workshops organized for the purpose of process dis- 
covery (cf. Chap. 5), workshop participants will often feel compelled to voice out 
issues related to different parts of the process. Therefore, process discovery is an 
occasion to start listing issues. Naturally, during process discovery, the documenta- 
tion of issues is left incomplete because the focus is more on understanding the as-is 
process. Additional analysis after the process discovery phase is required in order to 
document the issues and their impact in detail. 

Another framework commonly used for qualitative process analysis is the Theory 
of Constraints (TOC) [23]. TOC is especially useful when the goal is to trace weak- 
nesses in the process to specific bottlenecks. In addition to providing a framework 
for process analysis, TOC also provides guidance to identify, plan and implement 
changes in order to address the identified bottlenecks. The application of TOC to 
business process analysis and redesign is discussed at length by Laguna and Mark- 
lund [43, Chap. 5] and by Rhee et al. [76]. 

Finally, a useful framework when it comes to analyzing individual tasks (or ac- 
tivities) in a business process—as opposed to the entire process—is provided by 
Harmon [31, Chap. 10].* This so-called Task Analysis or Activity Analysis frame- 
work includes a comprehensive collection of questions and checklists that an analyst 
should answer and complete in order to identify opportunities to improve the per- 
formance of a given activity. 


The sub-categorization of the 6M’s given in Sect. 6.2.1 also comes from Schwegmann and 
Laske [84]. 


3 An alternate reference describing this framework is [32]. 


Chapter 7 
Quantitative Process Analysis 


It is better to be approximately right than precisely wrong. 
Warren Buffett (1930-) 


Qualitative analysis is a valuable tool to gain systematic insights into a process. 
However, the results obtained from qualitative analysis are sometimes not detailed 
enough to provide a solid basis for decision making. Think of the process owner of 
BuildIT’s equipment rental process preparing to make a case to the company’s COO 
that every site engineer should be given a tablet computer with wireless access in 
order to query suppliers’ catalogs and to make rental requests from any construction 
site. The process owner will be asked to substantiate this investment in quantitative 
terms and specifically to estimate how much time and money would be saved by 
doing this investment. To make such estimates, we need to go beyond qualitative 
analysis. 

This chapter introduces a range of techniques for analyzing business processes 
quantitatively, in terms of performance measures such as cycle time, total waiting 
time and cost. Specifically, the chapter focuses on three techniques: flow analysis, 
queueing analysis and simulation. All these techniques have in common that they 
allow us to calculate performance measures of a process, given data about the per- 
formance of individual activities and resources in the process. 


7.1 Performance Measures 


7.1.1 Process Performance Dimensions 


Any company would ideally like to make its processes faster, cheaper, and better. 
This simple observation leads us already to identifying three process performance 
dimensions: time, cost and quality. A fourth dimension gets involved in the equa- 
tion once we consider the issue of change. A process might perform extremely well 
under normal circumstances, but then perform poorly in other circumstances which 
are perhaps equally or more important. For example, van der Aalst et al. [98] re- 
port the story of a business process for handling claims at an Australian insurance 
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company. Under normal, everyday conditions, the process was performing to the 
entire satisfaction of all managers concerned (including the process owner). How- 
ever, Australia is prone to storms and some of these storms cause serial damages 
to different types of properties (e.g. houses and cars), leading to numerous claims 
being lodged in a short period of time. The call center agents and backoffice workers 
involved in the process were over-flooded with claims and the performance of the 
process degraded—precisely at the time when the customers were most sensitive to 
this performance. What was needed was not to make the process faster, cheaper or 
better during normal periods. Rather, it was needed to make the process more flexi- 
ble to sudden changes in the amount of claims. This observation leads us to identify 
a fourth dimension of process performance, namely flexibility. 

Each of the four performance dimensions mentioned above (time, cost, qual- 
ity, and flexibility) can be refined into a number of process performance measures 
(also called key performance indicators or KPIs). A process performance measure 
is a quantity that can be unambiguously determined for a given business process— 
assuming of course that the data to calculate this performance measure is available. 

For example, there are several types of cost such as cost of production, cost of 
delivery or cost of human resources. Each of these types of cost can be further 
refined into specific performance measures. To do so, one needs to select an aggre- 
gation function, such as count, average, variance, percentile, minimum, maximum, 
or ratios of these aggregation functions. A specific example of a cost performance 
measure is the average delivery cost per item. 

Below, we briefly discuss each of the four dimensions and how they are typically 
refined into specific performance measures. 


Time Often the first performance dimension that comes to mind when analyzing 
processes is time. Specifically, a very common performance measure for processes 
is cycle time (also called throughput time). Cycle time is the time that it takes to 
handle one case from start to end. Although it is usually the aim of a redesign effort 
to reduce cycle time, there are many different ways of further specifying this aim. 
For example, one can aim at a reduction of the average cycle time or the maximal 
cycle time. It is also possible to focus on the ability to meet cycle times that are 
agreed upon with a client at run time. Yet another way of looking at cycle time is 
to focus on its variation, which is notably behind approaches like Six Sigma (cf. 
Chap. 1). Other aspects of the time dimension come into view when we consider the 
constituents of cycle time, namely: 


1. Processing time (also called service time): the time that resources (e.g. process 
participants or software applications invoked by the process) spend on actually 
handling the case. 

2. Waiting time: the time that a case spends in idle mode. Waiting time includes 
queueing time—waiting time due to the fact that no resources available to handle 
the case—and other waiting time, for example because synchronization must 
take place with another process or because input is expected from a customer or 
from another external actor. 
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Cost Another common performance dimension when analyzing and redesigning 
a business process has a financial nature. While we refer to cost here, it would also 
have been possible to put the emphasis on turnover, yield, or revenue. Obviously, a 
yield increase may have the same effect on an organization’s profit as a decrease of 
cost. However, process redesign is more often associated with reducing cost. There 
are different perspectives on cost. In the first place, it is possible to distinguish be- 
tween fixed and variable cost. Fixed costs are overhead costs which are (nearly) not 
affected by the intensity of processing. Typical fixed costs follow from the use of 
infrastructure and the maintenance of information systems. Variable cost is posi- 
tively correlated with some variable quantity, such as the level of sales, the number 
of purchased goods, the number of new hires, etc. A cost notion which is closely 
related to productivity is operational cost. Operational costs can be directly related 
to the outputs of a business process. A substantial part of operational cost is usually 
labor cost, the cost related to human resources in producing a good or delivering 
a service. Within process redesign efforts, it is very common to focus on reducing 
operation cost, particularly labor cost. The automation of tasks is often seen as an 
alternative for labor. Obviously, although automation may reduce labor cost, it may 
cause incidental cost involved with developing the respective application and fixed 
maintenance cost for the life time of the application. 


Quality The quality of a business process can be viewed from at least two dif- 
ferent angles: from the client’s side and from the process participant’s side. This is 
also known as the distinction between external quality and internal quality. The ex- 
ternal quality can be measured as the client’s satisfaction with either the product or 
the process. Satisfaction with the product can be expressed as the extent to which a 
client feels that the specifications or expectations are met by the delivered product. 
On the other hand, a client’s satisfaction with the process concerns the way how it 
is executed. A typical issue is the amount, relevance, quality, and timeliness of the 
information that a client receives during execution on the progress being made. On 
the other hand, the internal quality of a business process related to the process par- 
ticipants’ viewpoint. Typical internal quality concerns are: the level that a process 
participants feels in control of the work performed, the level of variation experi- 
enced, and whether working within the context of the business process is felt as 
challenging. It is interesting to note that there are various direct relations between 
the quality and other dimensions. For example, the external process quality is often 
measured in terms of time, e.g., the average cycle time or the percentage of cases 
where deadlines are missed. In this book, we make the choice that whenever a per- 
formance measure refers to time, it is classified under the time dimension even if 
the measure is also related to quality. 


Flexibility The criterion that is least noted to measure the effect of a redesign 
measure is the flexibility of a business process. Flexibility can be defined in general 
terms as the ability to react to changes. These changes may concern various parts of 
the business process, for example: 
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e The ability of resources to execute different tasks within a business process set- 
ting. 

e The ability of a business process as a whole to handle various cases and changing 
workloads. 

e The ability of the management in charge to change the used structure and alloca- 
tion rules. 

e The organization’s ability to change the structure and responsiveness of the busi- 
ness process to wishes of the market and business partners. 


Another way of approaching the performance dimension of flexibility is to dis- 
tinguish between run time and build time flexibility. Run time flexibility concerns the 
opportunities to handle changes and variations while executing a specific business 
process. Build time flexibility concerns the possibility to change the business pro- 
cess structure. It is increasingly important to distinguish the flexibility of a business 
process from the other dimensions. 


Example 7.1 Let us consider the following scenario. 


A restaurant has recently lost many customers due to poor customer service. The manage- 
ment team has decided to address this issue first of all by focusing on the delivery of meals. 
The team gathered data by asking customers about how quickly they liked to receive their 
meals and what they considered as an acceptable wait. The data suggested that half of the 
customers would prefer their meals to be served in 15 minutes or less. All customers agreed 
that a waiting time of 30 minutes or more is unacceptable. 


In this scenario, it appears that the most relevant performance dimension is time, 
specifically serving time. One objective that distills from the scenario is to com- 
pletely avoid waiting times above 30 minutes. In other words, the percentage of 
customers served in less than 30 minutes should be as close as possible to 100 %. 
Thus, “percentage of customers served in less than 30 minutes” is a relevant perfor- 
mance measure. Another threshold mentioned in the scenario is 15 minutes. There 
is a choice between aiming to have an average meal serving time below 15 minutes 
or again, minimizing the number of meals served above 15 minutes. In other words, 
there is a choice between two performance measures: “average meal delivery time” 
or “percentage of customers served in 15 minutes”. 


This example illustrates that the definition of performance measures is tightly 
connected to the definition of performance objectives. In this respect, one possible 
method for deriving performance measures for a given process is the following: 


1. Formulate performance objectives of the process at a high level, in the form of 
a desirable state that the process should ideally reach, e.g. “customers should be 
served in less than 30 minutes”. 

2. For each performance objective, identify the relevant performance dimension(s) 
and aggregation function(s), and from there, define one or more performance 
measures for the objective in question, e.g. “percentage of customers served in 
less than 30 minutes”. Let us call this measure ST30. 

3. Define a more refined objective based on this performance measure, such as 
ST39 > 99 %. 
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During the redesign and implementation phases, a possible additional step is to 
attach a timeframe to the refined performance objective. For example, one can state 
that the above performance objective should be achieved in 12 months time. A per- 
formance objective with a timeframe associated to it is usually called a performance 
target. At the end of the chosen timeframe, one can assess to what extent the re- 
designed process has attained its targets. 


Exercise 7.1 Consider the travel agency scenario described in Exercise 6.6 
(p. 208). 


1. Which business processes should the travel agency improve? 
2. For each of the business processes you identified above, indicate which perfor- 
mance measure should the travel agency improve. 


7.1.2 Balanced Scorecard 


Another way of classifying and defining performance measures is given by the con- 
cept of Balanced Scorecard. The Balanced Scorecard is essentially an approach to 
align the goals and measures that are used to evaluate the work of managers. The 
main argument behind the Balanced Scorecard is that it is not sufficient to use finan- 
cial metrics, such as Return-On-Investment (ROJ) or operating margin, when eval- 
uating managers. An extreme focus on these measures is in the long-term detriment 
to the company as it neglects fundamental sources of value, namely the customer, 
the company’s internal structure and the company’s employees. Accordingly, the 
Balanced Scorecard is based on four performance dimensions—each one covering 
a fundamental concern of a company: 


e Financial Measures, e.g. cash flow, to ensure survival, operating margin to ensure 
shareholder satisfaction. 

e Internal Business Measures, e.g. cycle time, to ensure efficiency and low levels 
of inventory in the case of manufacturing organizations. 

e Innovation and Learning Measures, e.g. technology leadership, to ensure compet- 
itive advantage and to attract and retain talent. 

e Customer Measures, e.g. on-time delivery, to ensure customer satisfaction and 
loyalty. 


The classical way to implement the Balanced Scorecard follows a top-down pro- 
cedure. It begins with a corporate scorecard, followed by departmental ones with an 
emphasis on goals and metrics directly affected by the specific department. Process- 
related measures tend to appear only at the level of heads of units or their subordi- 
nates. This classical implementation of the Balanced Scorecard overemphasizes the 
functional division of organizations not paying enough attention to processes view. 
Companies implementing the Balanced Scorecard in conjunction with BPM need to 
carefully consider the relation between the measures in the Balanced Scorecard— 
both at the corporate level, departmental level and lower levels—and the perfor- 
mance measures associated with their business processes. One way to ensure this 


218 7 Quantitative Process Analysis 


alignment is to implement a Balanced Scorecard structured according to the com- 
pany’s process architecture (cf. Chap. 2). This process-oriented Balanced Scorecard 
may co-exist with a Balanced Scorecard that is traditionally associated to the com- 
pany’s functional architecture. 

In any case, we observe that the Balanced Scorecard is a useful tool for identify- 
ing process performance measures across an entire organization. This is in contrast 
with the method based on performance dimensions outlined in Sect. 7.1.1 is geared 
towards identifying performance measures for one given process. Thus, this latter 
method and the Balanced Scorecard are complementary. 


7.1.3 Reference Models and Industry Benchmarks 


Reference process models—previously mentioned in Chap. 2—provide another ba- 
sis to identify process performance measures. For instance, within the Supply Chain 
Operations Reference Model (SCOR), processes and activities in the process hier- 
archy are linked to performance measures. An example of a performance measure 
in SCOR is the “Purchase Order Cycle Time”, defined as the “average amount of 
time (e.g. days) between the moment an intention to purchase is declared and the 
moment the corresponding purchase order is received by the relevant vendor”. This 
is basically the average cycle time of a fragment of a procure-to-pay process. Other 
measures in SCOR deal with inventory management or out-of-stock events. In ad- 
dition to defining performance measures, SCOR also provides threshold values for 
each measure that allow a company to compare itself against peers within its indus- 
try and to determine whether they are in the top-10 %, top-50 % or bottom-50 % 
with respect to other companies in their industry sector. 

Another relevant framework mentioned in Chap. 2 is APQC’s Process Classifi- 
cation Framework (PCF). The primary aim of this framework is to provide a stan- 
dardized decomposition of processes in an organization together with standardized 
names and definitions for these processes. As a complement to PCF, APQC has also 
developed a set of performance measures for the processes included in PCF. This is 
also a potentially useful tool for performance measure identification. 

Yet another example of a reference model that provides a catalog of process 
performance measures is the IT Infrastructure Library—ITIL. ITIL’s performance 
measures include, for example, “Incidents due to Capacity Shortages” defined as the 
“number of incidents occurring because of insufficient service or component capac- 
ity”. This performance measure is linked to ITIL’s Capacity Management process 
area, which includes a number of inter-related processes to manage the capacity of 
IT processes or components of an IT system. 

Other reference models that provide catalogs of process performance measures 
include DCOR (Design Chain Operations Reference model) and eTOM (Enhanced 
Telecom Operations Map). 
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7.2 Flow Analysis 


Flow analysis is a family of techniques that allow us to estimate the overall perfor- 
mance of a process given some knowledge about the performance of its activities. 
For example, using flow analysis we can calculate the average cycle time of an en- 
tire process if we know the average cycle time of each activity. We can also use flow 
analysis to calculate the average cost of a process instance knowing the cost-per- 
execution of each activity, or calculate the error rate of a process given the error rate 
of each activity. 

In order to understand the scope and applicability of flow analysis, we start by 
showing how flow analysis can be used to calculate the average cycle time of a 
process. As a shorthand, we will use the term cycle time to refer to average cycle 
time in the rest of this chapter. 


7.2.1 Calculating Cycle Time Using Flow Analysis 


We recall that the cycle time of a process is the average time it takes between the 
moment the process starts and the moment it completes. By extension, we say that 
the cycle time of an activity is the average time it takes between the moment the 
activity is ready to be executed and the moment it completes. 

To understand how flow analysis works, it is useful to start with an example 
of a purely sequential process as in Fig. 7.1. The cycle time of each activity is 
indicated between brackets. Since the two activities in this process are performed 
one after the other, we can intuitively conclude that the cycle time of this process 
is 20 + 10 = 30. More generally, it is quite intuitive that the cycle time of a purely 
sequential fragment of a process is the sum of the cycle times of the activities in the 
fragment. 

When a process model or a fragment of a model contains gateways, the cycle 
time is no longer the sum of the activity cycle times. Let us consider the example 
shown in Fig. 7.2. Here, it is clear that the cycle time of the process is not 40 (the 
sum of the activity cycle times). Indeed, in a given instance of this process, either 
activity B or activity C is performed. If B is performed, the cycle time is 30, while 
if C is performed, the cycle time is 20. 

Whether the cycle time of this process is closer to 20 or closer to 30 depends 
on how frequently each branch of the XOR-split is taken. For instance, if in 50 % 
of instances the upper branch is taken and the remaining 50 % of instances the 
lower branch is taken, the overall cycle time of the process is 25. However, if the 
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upper branch is taken only 10 % of the times and the lower branch is taken 90 % 
of the times, the cycle time should be intuitively closer to 30. Generally speaking, 
the cycle time of the fragment of the process between the XOR-split and the XOR- 
join is the weighted average of the cycle times of the branches in-between. Thus, if 
the lower branch has a frequency of 10 % and the upper branch has a frequency of 
90 %, the cycle time of the fragment between the XOR-split and the XOR-join is: 
0.1 x 10+ 0.9 x 20 = 19. We then need to add the cycle time of activity A (which 
is always executed) in order to obtain the total cycle time, that is, 10 + 19 = 29. 
In the rest of this chapter, we will use the term branching probability to denote the 
frequency with which a given branch of a decision gateway is taken. 

In more general terms, the cycle time of a fragment of a process model with the 
structure shown in Fig. 7.3 is 


n 
CT=) 0 pi x 7; (7.1) 
i=l 


In Fig. 7.3, pi, p2, etc. are the branching probabilities. Each “cloud” represents 
a fragment that has a single entry flow and a single exit flow. The cycle times of 
these nested fragments are 7), T>, etc. Hereon, this type of fragment is called a 
XOR-block. 

Let us now consider the case where parallel gateways are involved as illustrated 
in Fig. 7.4. 

Again, we can observe that the cycle time of this process cannot be 40 (the sum 
of the activity cycle times). Instead, since tasks B and C are executed in parallel, 
their combined cycle time is determined by the slowest of the two activities, that is, 
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Fig. 7.6 Credit application process 


by C. Thus, the cycle time of the process shown in Fig. 7.4 is 10 + 20 = 30. More 
generally, the cycle time of an AND-block such as the one shown in Fig. 7.5 is 


CT = Max(T, To, ..., Tn) (7.2) 


Example 7.2 Let us consider the credit application process model in Fig. 7.6 and 
the activity cycle times given in Table 7.1. Let us also assume that in 60 % of cases, 
the credit is granted. 

To calculate the cycle time of this process, we first note that the cycle time of 
the AND-block is 3 days (slowest activity). Next, we calculate the cycle time of the 
fragment between the XOR-block using (7.1), that is, 0.6 x 1+ 0.4 x 2 = 1.4 days. 
The total cycle time is then 1 +3+3+1.4=8.4 days. 

In this example the cycle time is in great part determined by task “Check income 
sources”, which is the one that determines the cycle time of the fragment between 
the AND-split and the AND-join. In this case, we say that this task is part of the 
critical path of the process. The critical path of a process is the sequence of tasks that 
determines the cycle time of the process, meaning that the cycle time of any instance 
of the process is never lower than the sum of the cycle times of this sequence of 
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Table 7.1 Cycle times for 


credit application process Activity Cycle time 
Check completeness 1 day 
Check credit history 1 day 
Check income sources 3 days 
Assess application 3 days 
Make credit offer 1 day 
Notify rejection 2 days 


Fig. 7.7 Example of a 
rework loop 


tasks. When optimizing a process with respect to cycle time, one should focus the 
attention on tasks that belong to the critical path. 


Exercise 7.2 Consider the process model given in Fig. 3.8 (p. 73). Calculate the 
cycle time under the following assumptions: 


Each task in the process takes 1 hour on average. 

In 40 % of the cases the order contains only Amsterdam products. 
In 40 % of the cases it contains only Hamburg products. 

In 20 % of the cases it contains products from both warehouses. 


Compare the process model in Fig. 3.8 (p. 73) with the one in Fig. 3.10 (p. 74). 
Does this comparison give you an idea of how to calculate cycle times for process 
models with OR gateways? 


Another recurrent case worth considering is the case where a fragment of a pro- 
cess may be repeated multiple times. This situation is called rework and is illustrated 
in Fig. 7.7. Here the decimal numbers attached to the arcs denote the probability 
that the corresponding arc will be taken. For sure, we can say that activity B will 
be executed once. Next, we can say that activity B may be executed twice with a 
probability of 20 % (i.e. 0.2), which is the probability of going back from the XOR- 
split gateway to the XOR-join gateway. If we continue this reasoning, we find out 
that the probability that task B is executed three times is 0.2 x 0.2 = 0.04, and more 
generally, the probability that task B is executed N times is 0.2. 

If we sum up the cycle times in the cases where B is executed once, twice, three 
times, etc., we get the following summation }°?° 0.2'. In essence, this is the num- 
ber of times that B is expected to be executed. If we replace 0.2 with a variable r, 
this summation is a well-known series, known as the geometric series and it can 
be shown that this series is equivalent to 1/(1 — r). Hence, the average number of 
times that B is expected to be executed is 1/(1 — 0.2) = 1.25. Now, if we multiply 
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this expected number of instances of B times the cycle time of activity B, we get 
1.25 x 20 = 25. Thus the total cycle time of the process in Fig. 7.7 is 10 + 25 = 35. 
More generally, the cycle time of the fragment with the structure shown in 
Fig. 7.8 is 
T 


CT = : 
l-r 


(7.3) 


In this formula, parameter r is called the rework probability, that is, the proba- 
bility that the fragment inside the cycle will need to be reworked. From here on, this 
type of block will be called a rework block, or more generally a repetition block. 

In some scenarios, an activity is reworked at most once. This situation would be 
modeled as shown in Fig. 7.9. Using what we have seen, we can already calculate 
the cycle time of this example. First, we observe that the cycle time of the fragment 
between the XOR-split and the XOR-join is 0.2 x 20+ 0.8 x 0 = 4. Here, the zero 
comes from the fact that one of the branches between the XOR-split and the XOR- 
join is empty and therefore does not contribute to the cycle time. To complete this, 
we have to add the cycle time of the preceding activities, giving us a total cycle time 
of 34. 


Example 7.3 Let us consider the credit application process model in Fig. 7.10 and 
the cycle times previously given in Table 7.1. Let us also assume that in 20 % of the 
cases, the application is incomplete and in 60 % of cases the credit is granted. 

The cycle time of the rework block is 10/(1 — 0.2) = 1.25 days. The cycle time 
of the AND-block is 3 days and that of the XOR-block is 1.4 days as discussed in 
Example 7.2. Thus the total cycle time is 1.25+3+3+1.4 = 8.65 days. 
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7.2.2 Cycle Time Efficiency 


As previously mentioned, the cycle time of an activity or of a process can be divided 
into waiting time and processing time. Waiting time is the portion of the cycle time 
where no work is being done to advance the process. This includes time spent in 
transferring information about the case between process participants, like for exam- 
ple when documents are exchanged by post, as well as time when the case is waiting 
for an actor to process it. Processing time on the other hand refers to the time that 
actors spend doing actual work. In many if not most processes, the waiting time 
makes up a considerable proportion of the overall cycle time. There are a variety of 
reasons for this phenomenon. For example, this situation may happen because work 
is performed in batches. In a process related to the approval of purchase requisitions 
at a company, the supervisor responsible for such approvals in a business unit might 
choose to batch all applications and check them only once at the start or the end of 
a working day. Also, sometimes waiting time is spent waiting for an external actor 
to provide some input for a task. For example, in the context of fulfilling a medical 
prescription, a pharmacist may require a clarification from the doctor. To do so, the 
pharmacist would try to call the doctor. But the doctor might be unavailable and so 
the pharmacist needs to put the prescription aside and wait until the doctor returns 
the call. 

When analyzing a process with the aim of addressing issues related to cycle time, 
it may be useful to start by evaluating the ratio of overall processing time relative 
to the overall cycle time. This ratio is called cycle time efficiency. A cycle time 
efficiency close to 1 indicates that there is little room for improving the cycle time 
unless relatively radical changes are introduced in the process. A ratio close to zero 
indicates that there is a significant amount of room for improving cycle time by 
reducing the waiting time, for example due to handovers between participants. 

The cycle time efficiency of a process can be calculated as follows. First, we 
need to determine the cycle time and the processing time of each activity. Given 
this information, we can then calculate the overall cycle time of the process using 
the same formulas we saw above. Let us call this amount CT. Next, using the same 
formulas, we can calculate the overall amount of time that is spent doing actual 
work. This is called the theoretical cycle time of the process. Essentially, this is the 
amount of time that an instance of the process would take if there was no waiting 
time at all. To calculate the theoretical cycle time, we apply the same method as for 
calculating cycle time, but instead of using the cycle time of each activity, we use 
the processing time of each activity. Let us call the theoretical cycle time TCT. The 
cycle time efficiency (CTE) is then calculated as follows: 

TCT 


CTE = —— 
CT 


Example 7.4 Let us consider the credit application process model in Fig. 7.10 and 
the processing times given in Table 7.2. The activity cycle times (including both 
waiting and processing time) are those previously given in Table 7.1. Let us assume 
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Table 7.2 Processing times 


for credit application process Activity Cycle time 
Check completeness 2 hours 
Check credit history 30 minutes 
Check income sources 3 hours 
Assess application 2 hours 
Make credit offer 2 hours 
Notify rejection 30 minutes 

Table 7.3 Activity cycle ia ; Sa 

times and processing times Activity Cycle time — Processing time 

for ministerial enquiry 

process Register ministerial enquiry 2 days 30 mins 
Investigate ministerial enquiry 8 days 12 hours 
Prepare ministerial response 4 days 4 hours 
Review ministerial response 4 days 2 hour 


that in 20 % of cases, the application is incomplete and in 60 % of cases the credit 
is “granted”. Let us additionally assume that one day is equal to 8 working hours. 

We have seen in Example 7.3 that the total cycle time of this process is 8.65 days, 
which translates to 69.2 working hours. We now calculate the theoretical cycle time 
in the same way as the total cycle time but using the processing times given in 
Table 7.2. This gives us: 2/(1 — 0.2) +3+2+0.6 x 2+0.4 x 0.5 = 9.9 working 
hours. The cycle time efficiency is thus 8.9/69.2 = 12.9 %. 


Exercise 7.3 Calculate the overall cycle time, theoretical cycle time and cycle time 
efficiency of the ministerial enquiry process introduced in Exercise 3.7 (p. 77). As- 
sume that the rework probability is 0.2 and that the waiting times and processing 
times are those given in Table 7.3. 


7.2.3 Cycle Time and Work-In-Process 


Cycle time is directly related to two measures that play an important role when 
analyzing a process, namely arrival rate and Work-In-Process (WIP). 

The arrival rate of a process is the average number of new instances of the process 
that are created per time unit. For example, in a credit application process, the arrival 
rate is the number of credit applications received per day (or any other time unit we 
choose). Similarly, in an order-to-cash process, the arrival rate is the average number 
of new orders that arrive per day. Traditionally, the symbol A is used to refer to the 
arrival rate. 

Meanwhile, WIP is the average number of instances of a process that are active 
at a given point in time, meaning the average number of instances that have not 
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yet completed. For example, in a credit application process, the WIP is the aver- 
age number of credit applications that have been submitted and not yet granted or 
rejected. Similarly, in an order-to-cash process, the WIP is the average number of 
orders that have been received but not yet delivered and paid. 

Cycle time (CT), arrival rate (1) and WIP are related by a fundamental law known 
as Little’s law, which states that: 


WIP =i x CT 
Basically what this law tells us is that: 


e WIP increases if the cycle time increases or if the arrival rate increases. In other 
words, if the process slows down—meaning that its cycle time increases—there 
will be more instances of the process active concurrently. Also, the faster new 
instances are created, the higher will be the number of instances in an active 
State. 

e If the arrival rate increases and we want to keep the WIP at current levels, the 
cycle time must decrease. 


Little’s law holds for any stable process. By stable, we mean that the number of 
active instances is not increasing infinitely. In other words, in a stable process, the 
amount of work waiting to be performed is not growing beyond control. 

Although simple, Little’s law can be an interesting tool for what-if analysis. We 
can also use Little’s law as an alternative way of calculating total cycle time of a 
process if we know the arrival rate and WIP. This can be useful sometimes because 
determining the arrival rate and WIP is sometimes easier than determining the cycle 
time. For example, in the case of the credit application process, the arrival rate can 
be easily calculated if we know the total number of applications processed over a 
period of time. For example, if we assume there are 250 business days per year 
and we know the total number of credit applications over the last year is 2500, 
we can infer that the average number of applications per business day is 10. WIP 
on the other hand can be calculated by means of sampling. We can ask how many 
applications are active at a given point in time, then ask this question again one week 
later and again two weeks later. Let us assume that on average we observe that 200 
applications are active concurrently. The cycle time is then WIP/A = 200/10 = 20 
business days. 


Exercise 7.4 A restaurant receives on average 1,200 customers per day (between 
10am and 10pm). During peak times (12pm to 3pm and 6pm to 9pm), the restaurant 
receives around 900 customers in total and, on average, 90 customers can be found 
in the restaurant at a given point in time. At non-peak times, the restaurant receives 
300 customers in total and, on average, 30 customers can be found in the restaurant 
at a given point in time. 


e What is the average time that a customer spends in the restaurant during peak 
times? 

e What is the average time that a customer spends in the restaurant during non-peak 
times? 
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e The restaurant’s premises have a maximum capacity of 110 customers. This max- 
imum capacity is sometimes reached during peak times. The restaurant manager 
expects that the number of customers during peak times will increase slightly 
in the coming months. What can the restaurant do to address this issue without 
investing in extending its building? 


7.2.4 Other Applications and Limitations of Flow Analysis 


As mentioned earlier, flow analysis can also be used to calculate other performance 
measures besides cycle time. For example, assuming we know the average cost of 
each activity, we can calculate the cost of a process more or less in the same way as 
we calculate cycle time. In particular, the cost of a sequence of activities is the sum 
of the costs of these activities. Similarly the cost of an XOR-block is the weighted 
average of the cost of the branches of the XOR-block, and the cost of a rework 
pattern such as the one shown in Fig. 7.8 is the cost of the body of the loop divided 
by 1 —r. The only difference between calculating cycle time and calculating cost 
relates to the treatment of AND-blocks. The cost of an AND-block such as the one 
shown in Fig. 7.5 is not the maximum of the cost of the branches of the AND-block. 
Instead, the cost of such a block is the sum of the costs of the branches. This is 
because after the AND-split is traversed, every branch in the AND join is executed 
and therefore the costs of these branches add up to one another. 


Example 7.5 Let us consider again the credit application process model in Fig. 7.10 
and the processing times given in Table 7.2. As previously, we assume that in 20 % 
of cases, the application is incomplete and in 60 % of cases the credit is granted. 
We further assume that activities “Check completeness”, “Check credit history” and 
“Check income sources” are performed by a clerk, while activity “Assess applica- 
tion’, “Make credit offer’ and “Notify rejection” are performed by a credit officer. 
The hourly cost of a clerk is 25 while the hourly cost of a credit officer is 50. Per- 
forming a credit history requires that the bank submits a query to an external system. 
The bank is charged € 1 per query by the provider of this external system. 

From this scenario, we can see that the cost of each task can be split into two 
components: the human resource cost and other costs. The human resource cost is 
the cost of the human resource(s) that performs the task. This can be calculated as 
the product of the hourly cost of the resource and the processing time (in hours) of 
the task. Other costs correspond to costs that are incurred by an execution of a task, 
but are not related to the time spent by human resources in the task. In this example, 
the cost per query to the external system would be classified as “other costs” for task 
“Check credit history”. The remaining tasks do not have an “other cost” component. 
For the example at hand, the breakdown of resource cost, other cost and total cost 
per task is given in Table 7.4. Given this input, we can calculate the total cost-per- 
execution of the process as follows: 50/(1 — 0.2) + 13.5 +75 + 100 +0.6 x 100+ 
0.4 x 25 = 321. 
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Table 7.4 Cost calculation 


table for credit application Activity Resource cost Other cost Total cost 
process 
Check completeness 2 x 25=50 0 50 
Check credit history 0.5x25=12.5 1 13.5 
Check income sources 3 x 25 =75 0 715 
Assess application 2 x 50= 100 0 50 
Make credit offer 2 x 50= 100 0 100 
Notify rejection 0.5x50=25 0 25 


Exercise 7.5 Calculate the cost-per-execution of the ministerial enquiry process 
introduced in Exercise 3.7 (p. 77). Assume that the rework probability is 0.2 and 
that the times are those given in Table 7.3. Activity “Register ministerial enquiry” 
is performed by a clerk, activity “Investigate ministerial enquiry” is performed by 
an adviser, “Prepare ministerial response” is performed by a senior adviser, and 
“Review ministerial response” is performed by a minister counselor. The hourly 
resource cost of a clerk, adviser, senior adviser and minister counselor are 25, 50, 
75, and 100, respectively. There are no other costs attached to these activities besides 
the resource costs. 


Before closing the discussion on flow analysis, it is important to highlight some 
of its pitfalls and limitations. First of all, we should note that the equations presented 
in Sect. 7.2.1 do not allow us to calculate the cycle time of any process model. In 
fact, these equations only work in the case of block-structured process models. In 
particular, we cannot use these equations to calculate the cycle time of an unstruc- 
tured process model such as the one shown in Exercise 3.9 (p. 93). Indeed, this ex- 
ample does not fit into any of the patterns we have seen above. Calculating the cycle 
time in this case is trickier. Also, if the model contains other modeling constructs 
besides AND and XOR gateways, the method for calculating cycle time becomes 
more complicated. 

Fortunately, this is not a fundamental limitation of flow analysis, but only a limi- 
tation of the specific set of equations discussed in Sect. 7.2.1. There are other more 
sophisticated flow analysis techniques that allow us to calculate the cycle time of 
virtually any process model. The maths can get a bit more complex and in practice, 
one would not do such calculations by hand. But this is generally not a problem 
given that several modern process modeling tools include functionality for calculat- 
ing cycle time, cost, and other performance measures of a process model using flow 
analysis. 

A more fundamental roadblock faced by analysts when applying flow analysis 
is the fact that they first need to estimate the average cycle time of each activity in 
the process model. In fact, this obstacle is typical when applying any quantitative 
process analysis technique. There are at least two approaches to address this obsta- 
cle. The first one is based on interviews or observation. In this approach, analysts 
interview the stakeholders involved in each task or they observe how the stakehold- 
ers work during a given day or period of time. This allows analysts to at least make 
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an “informed guess” regarding the average time a case spends in each activity, both 
in terms of waiting time and processing time. A second approach is to collect logs 
from the information systems used in the process. For example, if a given activity 
such as approving a purchase requisition is performed by means of an internal Web 
portal (an Intranet), the administrators of the portal should be able to extract logs 
from this portal that would allow the analyst to estimate the average amount of time 
that a requisition form spends in “waiting for approval” mode and also the average 
time between the moment the supervisor opens a purchase requisition for approval 
and the time they approve it. With careful analysis, these logs can provide a wealth 
of information that can be combined via flow analysis to get an overall picture of 
which parts of the process consume the most time. 

A major limitation of flow analysis is that it does not take into account the fact 
that a process behaves differently depending on the load, that is, depending on the 
amount of instances of the process that are running concurrently. Intuitively, the 
cycle time of a process for handling insurance claims would be much slower if 
the insurance company is handling thousands of claims at once, due for example 
to a recent natural disaster such as a storm, versus the case where the load is low 
and the insurance company is only handling a hundred claims at once. When the 
load goes up and the number of resources (e.g. claim handlers) remains relatively 
constant, it is clear that the waiting times are going to be longer. This is due to 
a phenomenon known as resource contention. Resource contention occurs when 
there is more work to be done than resources available to perform the work, like for 
example more claims than insurance claim handlers. In such scenarios, some tasks 
will be in waiting mode until one of the necessary resources are freed up. Flow 
analysis does not take into account the effects of increased resource contention. 
Instead, the estimates obtained from flow analysis are only applicable if the level of 
resource contention remains relatively stable over the long-run. 


7.3 Queues 


Queueing theory is a collection of mathematical techniques to analyze systems that 
have resource contention. Resource contention inevitably leads to queues as we all 
probably have experienced in supermarket check-out counters, at a bank’s office, 
post office or government agency. Queueing theory gives us techniques to analyze 
important parameters of a queue such as the expected length of the queue or the 
expected waiting time of an individual case in a queue. 


7.3.1 Basics of Queueing Theory 


In basic queueing theory, a gueueing system is seen as consisting of one or multiple 
queues and a service that is provided by one or multiple servers. The elements inside 
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a queue are called jobs or customers, depending on the specific context. For exam- 
ple, in the case of a supermarket, the service is that of checking out. This service 
is provided by multiple cashiers (the servers). Meanwhile, in the case of a bank of- 
fice, the service is to perform a banking transaction, the servers are tellers, and there 
is generally a single queue that leads to multiple servers (the tellers). These two 
examples illustrate an important distinction between multi-line (i.e. multi-queue) 
queueing systems (like the supermarket) and single-line queueing systems (like the 
bank office). 

Queueing theory provides a very broad set of techniques. It would be unrealis- 
tic to introduce all these techniques in this chapter. So instead of trying to present 
everything that queueing theory has to offer, we will present two queueing theory 
models that are relatively simple, yet useful when analyzing business processes or 
activities within a process. 

In the two models we will be presenting, there is a single queue (single-line 
queueing system). Customers come at a given mean arrival rate that we will call A. 
This is the same concept of arrival rate that we discussed above when presenting 
Little’s law. For example, we can say that customers arrive at the bank office at a 
mean rate of 20 per hour. This implies that, on average, one customer arrives every 
5 minutes (35 hour). This latter number is called the mean inter-arrival time. We 
observe that if 4 is the arrival rate per time unit, then 1/A is the mean inter-arrival 
time. 

It would be illusory to think that the time between the arrival of two customers 
at the post office is always 5 minutes. This is just the mean value. In practice, cus- 
tomers arrive independently from one another, so the time between the arrival of 
one customer and the arrival of the next customer is completely random. Moreover, 
let us say that the time between the arrival of the first customer and the arrival of 
the second customer is | minute. This observation does not tell us absolutely any- 
thing about the time between the arrival of the second customer and the arrival of 
the third customer. It might be that the third customer arrives 1 minute after the 
second, or 5 minutes or 10 minutes. We will not know until the third customer ar- 
rives. 

Such an arrival process is called a Poisson process. In this case, the distribution 
of arrivals between any two consecutive customers follows a so-called exponential 
distribution (specifically a negative exponential distribution) with a mean of 1/A. 
In a nutshell, this means that the probability that the inter-arrival time is exactly 
equal to ¢ (where ¢ is a positive number) decreases in an exponential manner when 
t increases. For instance, the probability of the time of inter-arrival time being 10 
is considerably smaller than the probability of the inter-arrival time being 1. Hence, 
shorter inter-arrival times are much more probable than longer ones, but there is 
always a probability (perhaps a very small one) that the inter-arrival time will be a 
large number. 

In practice, the Poisson process and the exponential distribution describe a large 
class of arrival processes that can be found in business processes, so we will be using 
them to capture the arrival of jobs or customers into a business process or an activity 
in a business process. The Poisson process can also be observed for example when 
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we examine how often cars enter a given segment of a highway, or how often calls 
go through a telephone exchange. 

Having said this, one must always cross-check that cases arrive to a given process 
or activity in an exponentially distributed manner. This cross-check can be done 
by recording the inter-arrival times for a given period of time, and then feeding 
these numbers into a statistical tool such as for example R, Mathworks’s Statistical 
Toolbox or EasyFit. These tools allow one to input a set of observed inter-arrival 
times and check if it follows a negative exponential distribution. 

Exponential distributions are not only useful when modeling the inter-arrival 
time. They are also in some cases useful when describing the processing time of 
an activity.! In the case of activities that require a diagnosis, a non-trivial verifi- 
cation or some non-trivial decision making, it is often the case that the activity’s 
processing time is exponentially distributed. Take for example the amount of time it 
takes for a mechanic to make a repair on a car. Most repairs are fairly standard, and 
the mechanics might take for example one hour to do them. However, some repairs 
are very complex, and in such cases, it can take the mechanic several hours to com- 
plete. A similar remark can be made of a doctor receiving patients in an emergency 
room. A large number of emergencies are quite standard and can be dispatched in 
less than an hour, but some emergencies are extremely complicated and can take 
hours to deal with. So it is likely that such activities will follow an exponential dis- 
tribution. As mentioned above, when making such a hypothesis, it is important that 
you first check it by taking a random sample of processing times and feeding them 
to a statistical tool. 

In the queueing theory field, a single-queue system is called an M/M/I queue if 
the inter-arrival times of customers follow an exponential distribution, the process- 
ing times follow an exponential distribution, there is one single server and jobs are 
served on a First-In-First-Out (FIFO) basis. In the case of M/M/1 queue, we also 
assume that when a job arrives, it enters the queue and it stays there until it is taken 
on by the server. 

If the above conditions are satisfied, but there are multiple servers instead of a 
single server, the queueing system is said to be M/M/c, where c is number of servers. 
For example, a queue is M/M/5 if the inter-arrival times of customers follow an 
exponential distribution, the processing times follow an exponential distribution and 
there are five servers at the end of the queue. The “M” in this denomination stands 
for “Markovian”, which is the name given to the assumptions that inter-arrival times 
and processing times follow an exponential distribution. Other queueing models 
exist that make different assumptions. Each such model is different, so the results 
we will obtain for an M/M/1 or M/M/c queue are quite different from those we 
would obtain from other distributions. 


'In queueing theory, the term service time is used instead of processing time. For uniformity pur- 
poses, here we use the term processing time. 
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7.3.2 M/M/1 and M/M/c Models 


To summarize the previous discussion, an M/M/1 queue or M/M/c queue can be 
defined by means of the following parameters: 


e A—the mean arrival rate per time unit. The mean inter-arrival time is then 1/2. 
For example, A = 5 means that there are 5 arrivals per hour and this entails that 
the mean inter-arrival time between two consecutive jobs is 1/5 hours, that is 12 
minutes. 

e jz—the mean number of customers that can be served per time unit. The mean 
processing time per job is then 1/j. For example, 4p = 6 means six jobs are 
served per hour, that is, one job is served in 10 minutes (on average). 

e Inthe case of M/M/c, the number of servers (c). 


Given parameters A and jz, we can already state how busy a server is. This is 
called the occupation rate p and is equal to A/j. In the above example, the oc- 
cupation rate is 5/6 = 83.34 %. It should be noted that this is a relatively high 
occupation rate. A system with an occupation rate of more than 100 % is unstable, 
meaning that the queue will become longer and longer forever because the server 
cannot cope with all the demand. In fact, even a system at close to 100 % of occu- 
pation rate is unstable because of the randomness at which new jobs arrive and the 
variability in the processing times per job. To understand why this is the case, just 
imagine if you were a doctor receiving patients at a rate of 6 per hour for 8 hours, 
knowing that every patient takes 10 minutes on average to be treated (sometimes 
less but sometimes more). Without any slack, most likely you will end up with a 
tremendous backlog at the end of the day. 

In the case of an M/M/c system, the occupancy rate is a since the system can 
handle jobs at a rate of cu. For example, if the system has two servers and each 
server can handle two jobs per hour, the system can handle four jobs per hour. If jobs 
arrive at a mean rate of 3 per hour, the occupancy rate of the system is 3/4 = 75 %. 

Given an M/M/1 or M/M/c system, queueing theory allows us to calculate the 
following parameters: 


e L,—The average number of jobs (e.g. customers) in the queue. 

e W,—The average time one job spends in the queue. 

e W—tThe average time one job spends in the system. This includes both the time 
the customer spends in the queue but also the time the customer spends being 
serviced. 

e L—tThe average number of jobs in the system (i.e. the Work-in-Progress refer- 
enced in Little’s law). 


To summarize, the general structure of a single-queue system—consisting of one 
queue and one or many servers—is depicted in Fig. 7.11. The parameters of the 
queue (A, c and jz) are shown at the top. The parameters that can be computed 
from these three input parameters are shown under the queue and the server. The 
average time a job waits in the queue is W,, while the average length of the queue 
is Lg. Eventually, a job goes into the server and in there it spends on average 1/1 
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time units. The average time between the moment a job enters the system and the 
moment it exits is W, while the average number of jobs inside the system (in the 
queue or in a server) is L. 

Queueing theory gives us the following formulas for calculating the above pa- 
rameters for M/M/1 models: 


Ly=p°/(—p) (7.4) 
Lq 
Wa = ae (7.5) 
wei (7.6) 
[pL 
L=AW (7.7) 


Formulas (7.5), (7.6), and (7.7) can be applied to M/M/c models as well. The 
only parameter that needs to be calculated differently in the case of M/M/c models 
is Lg. For M/M/c models, Lg is given by the following formula: 


(A/M)<p 


cll — py HIBS, + Seach SRE 


The formula for computing L, in the case of M/M/c models is particularly com- 
plicated because of the summations and factorials. Fortunately, there are tools that 
can do this for us. For example, the Queueing Toolpack* supports calculations for 
M/M/c systems (called M/M/s in the Queueing Toolpack) as well as M/M/c/k sys- 
tems, where k is the maximum number of jobs allowed in the queue. Jobs that arrive 
when the length of the queue is k are rejected (and may come back later). Other 
tools for analyzing queueing systems include QSim? and PDQ.* 


(7.8) 


Example 7.6 A company designs customized electronic hardware for a range of 
customers in the high-tech electronics industry. The company receives orders for 
designing a new circuit every 20 working days on average. It takes a team of engi- 
neers on average 10 working days to design a hardware. 

This problem can be mapped to an M/M/1 model assuming that the arrival of 
designs follows a Poisson process, that the distribution of times for designing a 
circuit follows an exponential distribution and that new design requests are handled 


*http://apps. business. ualberta.ca/aingolfsson/qtp/. 
3http://www.stat.auckland.ac.nz/~stats255/qsim/qsim.html. 
*http://www.perfdynamics.com/Tools/PDQ.html. 
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on a FIFO manner. Note that even though the team includes several people, they act 
as a monolithic entity and therefore it should be treated as a single server. 

We will hereby take the working day as a time unit. On average, 0.05 orders are 
received per day (A = 0.05), and 0.2 orders are fulfilled per day (44 = 0.1). Thus, the 
occupation rate of this system p = 0.05/0.1 = 0.5. Using the formulas for M/M/1 
models, we can deduce that the average length of the queue L, is: 0.57/(1 — 0.5) = 
0.5 orders. From there we can conclude that the average time an order spends on 
the queue is W, = 0.5/0.05 = 10 days. Thus, it takes on average order W = 10 + 
1/0.1 = 20 working days for an order to be fulfilled. 


Exercise 7.6 Consider now the case where the engineering team in the previous 
example takes 16 working days to design a hardware. What is then the average 
amount of time an order takes to be fulfilled? 


Exercise 7.7 An insurance company receives 220 calls per day from customers who 
want to lodge an insurance claim. The call center is open from 8am to 5pm. The 
arrival of calls follows a Poisson process. Looking at the intensity of arrival of calls, 
we can distinguish three periods during the day: the period 8am to 11am, the period 
11am to 2pm and the period 2pm to 5pm. During the first period, around 60 calls are 
received. During the 1 lam—2pm period, 120 calls are received, and during the 2pm— 
Spm period, 40 calls are received. A customer survey has shown that customers tend 
to call between 11am and 2pm because during this time they have a break at work 
and they take advantage of their break to make their personal calls. 

Statistical analysis shows that the durations of calls follow an exponential distri- 
bution. 

According to the company’s customer service charter, customers should wait no 
more than one minute on average for their call to be answered. 


e Assume that the call center can handle 70 calls per hour using seven call center 
agents. Is this enough to meet the 1-minute constraint set in the customer service 
charter? Please explain your answer by showing how you calculate the average 
length of the queue and the average waiting time. 

What happens if the call center’s capacity is increased so that it can handle 80 

calls per hour (using eight call center agents)? 

e The call center manager has been given a mandate to cut costs by at least 20 %. 
Give at least two ideas to achieve this cut without reducing the salaries of the call 
center agents and while keeping an average waiting time below or close to one 
minute. 


7.3.3 Limitations of Basic Queueing Theory 


The basic queueing analysis techniques presented above allow us to estimate wait- 
ing times and queue length based on the assumptions that inter-arrival times and 
processing times follow an exponential distribution. When these parameters follow 
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different distributions, one needs to use very different queueing models. Fortunately, 
queueing theory tools nowadays support a broad range of queueing models and of 
course they can do the calculations for us. The discussion above was intended as an 
overview of single-queue models, with the aim of providing a starting point from 
where you can learn more about this family of techniques. 

A more fundamental limitation of the techniques introduced in this section is 
that they only deal with one activity at a time. When we have to analyze an entire 
process that involves several activities, events, and resources, these basic techniques 
are not sufficient. There are many other queueing analysis techniques that could be 
used for this purpose, like for example queueing networks. Essentially, queueing 
networks are systems consisting of multiple inter-connected queues. However, the 
maths behind queueing networks can become quite complex, especially when the 
process includes concurrent activities. A more popular approach for quantitative 
analysis of process models under varying levels of resource contention is process 
simulation, as discussed below. 


7.4 Simulation 


Process simulation is arguably the most popular and most widely supported tech- 
nique for quantitative analysis of process models. The basic idea underpinning pro- 
cess simulation is quite simple. In essence, a process simulator generates a large 
number of hypothetical instances of a process, executes these instances step-by- 
step, and records each step in this execution. The output of a simulator typically 
includes the logs of the simulation as well as some statistics related to cycle times, 
average waiting times and average resource utilization. 


7.4.1 Anatomy of a Process Simulation 


During a process simulation, the tasks in the process are not actually executed. In- 
stead, the simulation of a task proceeds as follows. When a task is ready to be exe- 
cuted, a so-called work item is created and the simulator first tries to find a resource 
to which it can assign this work item. If no resource able to perform the work item 
is found, the simulator puts the work item in waiting mode until a suitable resource 
is freed up. Once a resource is assigned to a work item, the simulator determines 
the duration of the work item by drawing a random number according to the proba- 
bility distribution of the task’s processing time. This probability distribution and the 
corresponding parameters need to be defined in the simulation model. 

Once the simulator has determined the duration of a work item, it puts the work 
item in sleeping mode for that duration. This sleeping mode simulates the fact that 
the task is being executed. Once the time interval has passed (according to the simu- 
lation’s clock), the work item is declared to be completed, and the resource that was 
assigned to it becomes available. 
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In reality, the simulator does not effectively wait for tasks to come back from their 
sleeping mode. For example, if the simulator determines that the duration of a work 
item is 2 days and 2 hours, it will not wait for this amount of time to pass by. You can 
imagine how long a simulation would take if that was the case. Luckily, simulators 
use smart algorithms to complete the simulation as fast as possible. Modern business 
process simulators can effectively simulate thousands of process instances and tens 
of thousands of work items in a matter of seconds. 

For each work item created during a simulation, the simulator records the identi- 
fier of the resource that was assigned to this instance as well as three time stamps: 


e The time when the task was ready to be executed. 
e The time when the task was started, meaning that it was assigned to a resource. 
e The time when the task completed. 


Using the collected data, the simulator can compute the average waiting time for 
each task. These measures are quite important when we try to identify bottlenecks 
in the process. Indeed, if a task has a very high average waiting time, it means that 
there is a bottleneck at the level of this task. The analyst can then consider several 
options for addressing this bottleneck. 

Additionally, since the simulator records which resources perform which work 
items and it knows how long each work item takes, the simulator can find out the 
total amount of time during which a given resource is busy handling work items. By 
dividing the amount of time that a resource was busy during a simulation by the total 
duration of the simulation, we obtain the resource utilization, that is, the percentage 
of time that the resource is busy on average.” 


7.4.2 Input for Process Simulation 


From the above description of how a simulation works, we can see that the following 
information needs to be specified for each task in the process model in order to 
simulate it: 


e Probability distribution for the processing time of each task. 

e Other performance attributes for the task such as cost and added-value produced 
by the task. 

e The set of resources that are able to perform the task. This set is usually called a 
resource pool. For example, a possible resource pool could be the “Claim Han- 
dlers” or “Clerks” or “Managers”. Separately, the analyst needs to specify for 
each resource pool the number of resources in this pool (e.g. the number of claim 
handlers or the number of clerks) and other attributes of these resources such as 
the hourly cost (e.g. the hourly cost of a claims handler). 


5Note that when discussing queueing theory above, we used the term occupation rate instead of 
resource utilization. These two terms are synonyms. 
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Common probability distributions for task durations in the context of process 
simulation include: 


e Fixed. This is the case where the processing time of the task is the same for all 
executions of this task. It is rare to find such tasks because most tasks, especially 
those involving human resources, would exhibit some variability in their process- 
ing time. Examples of tasks with fixed processing time can be found among au- 
tomated tasks such as for example a task that generates a report from a database. 
Such a task would take a relatively constant amount of time, say for example 5 
seconds. 

e Exponential distribution. As discussed in Sect. 7.3, the exponential distribution 
may be applicable when the processing time of the task is most often around a 
given mean value, but sometimes it is considerably longer. For example, consider 
a task “Assess insurance claims” in an insurance claims handling process. You can 
imagine that in most cases, the insurance claims fall within very standard cases. 
In such cases, the claim is assessed in an hour, or perhaps less. However, some 
insurance claims require special treatment, for example because the assessor con- 
siders that there is a risk that the claim is fraudulent. In this case, the assessor 
might spend several hours or even an entire day assessing a single claim. A sim- 
ilar observation can be made of diagnostics tasks, such as diagnosing a problem 
in an IT infrastructure, or diagnosing a problem during a car repair process. 

e Normal distribution. This distribution is used when the processing time of the task 
is around a given average, and the “deviation” around this value is symmetric, 
meaning that the actual processing time can be above or below the mean with the 
same probability. Simple checks, such as for example checking whether or not 
a paper form has been fully completed might follow this distribution. Indeed, it 
generally takes about 3 minutes to make such a check. In some cases, this time can 
be lower because for example the form is clearly incomplete or clearly complete, 
and in other cases it can take a bit longer because a couple of fields have been left 
empty and it is unclear if these fields are relevant or not for the specific customer 
who submitted the form. 


When assigning an exponential distribution to a task duration, the analyst has 
to specify the mean value. Meanwhile, when assigning a normal distribution, the 
analyst has to specify two parameters: mean value and standard deviation. These 
values are derived through an informed guess (based on interviews with the relevant 
stakeholders), but preferably by means of sampling (the analyst collects data for a 
sample of tasks executions) or by analyzing logs of relevant information systems. 
Some simulation tools allow the analyst to import logs into the simulation tool and 
assist the analyst in selecting the right probability distribution for task durations 
based on these logs. This functionality is called simulation input analysis. 

In addition to the above per-task simulation data, a branching probability needs 
to be specified for every arc stemming from a decision gateway. These probabilities 
are determined by interviewing relevant stakeholders, observing executions of the 
process during a certain period of time, or collecting logs from relevant information 
systems. 
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Finally, in order to run a simulation, the analyst additionally needs to specify at 
least the following: 


e The inter-arrival times and the mean arrival rate. As explained above, a very fre- 
quent distribution of inter-arrival times is the exponential distribution and this is 
usually the default distribution supported by business process simulators. It may 
happen, however, that the inter-arrival times follow a different distribution such 
as for example a normal distribution. By feeding a sample of inter-arrival times 
during a certain period of time to a statistical tool, we can find out which dis- 
tribution best matches the data. Some simulators provide a module for selecting 
a distribution for the inter-arrival times and for computing the mean inter-arrival 
time from a data sample. 

e The starting date and time of the simulation (e.g. “11 Nov. 2012 at 8:00”). 

e One of the following: 

— The end date and time of the simulation. If this option is taken, the simulation 
will stop producing more process instances once the simulation clock reaches 
the end time. 

— The real-time duration of the simulation (e.g. 7 days, 14 days). In this way, the 
end time of the simulation can be derived by adding this duration to the starting 
time. 

— The required number of process instances to be simulated (e.g. 1,000). If this 
option is taken, the simulator generates process instances according to the ar- 
rival rate until it reaches the required number of process instances. At this point, 
the simulation stops. Some simulators will not stop immediately, but will allow 
the active process instances to complete before stopping the simulation. 


Example 7.7 We consider the process for loan application approval modeled in 
Fig. 4.6 (p. 104). We simulate this model using the BIMP simulator available at: 
http://bimp.cs.ut.ee. This simulator takes as input BPMN process models in XML 
format produced by other process modeling tools such as Signavio Process Editor 
or OpenText Provision. We provide the following inputs for the simulation. 


e Two loan applications per hour, meaning an inter-arrival time of 30. 

e Tasks “Check credit history” and “Check income sources” are performed by 
clerks. 

e Tasks “Notify rejection”, “Make credit offer” and “Assess application” are per- 
formed by credit officers. 

e Task “Receive customer feedback” is in fact an event. It takes zero time and it only 
involves the credit information system (no human actors involved). To capture 
this, the task is assigned to a special “System” role. 

e There are three clerks and three credit officers. The hourly cost of a clerk is € 25 
while that of a credit officer is € 50. 

e Clerks and credit officers work from 9am to 5pm during weekdays. 

e The cycle time of task “Assess application” follows an exponential distribution 
with a mean of 20 minutes. 
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Fig. 7.12 Histograms produced by simulation of the credit application process 


e Cycle times of all other tasks follow a normal distribution. Tasks “Check credit 
history”, “Notify rejection” and “Make credit offer” have a mean cycle time of 
10 minutes with a 20 % standard deviation, while “Check income sources” has a 
cycle time of 20 minutes with a 20 % standard deviation as well. 

e The probability that an application is accepted is 80 %. 

e The probability that a customer whose application was rejected, asks that the 


application be re-assessed is 20 %. 


We run a simulation with 5,000 instances, which means around 104 days of 
loan applications arrivals assuming that applications arrive 24 hours a day, 7 days 
a week.® The simulation gives an average cycle time of around 17 hours. A vari- 
ance of +2 hours can be observed when running the simulation multiple times. This 
variance is expected due to the stochastic nature of the simulation. Accordingly, it 
is recommended to run the simulation multiple times and to take averages of the 
simulation results. Figure 7.12 shows the histograms for process cycle time (called 
process duration in BIMP), waiting time (time a case spends waiting for resources 
to become available), cost (of resources), and resource utilization. It can be seen 
that applications spend most of the time in waiting mode, waiting for resources to 
become available. Resource utilization of clerks and credit officers is at 85 % and 
88.5 %, respectively, meaning that there is some overload. As a rule of thumb, a 
resource utilization above 80 % means that one can expect long queues and high 
waiting times. If we add two clerks and two credit officers to the simulation we 
obtain an average cycle time of around 8 hours (compared to 17 hours) and an uti- 
lization rate of around 80 % for clerks and 50 % for credit officers. 


Some simulators additionally allow one to specify that new cases are only created during certain 
times of the day and certain days of the week, or according to a given calendar. 
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Exercise 7.8 An insurance company, namely Cetera, is facing the following prob- 
lem: Whenever there is a major event (e.g. a storm), their claim-to-resolution process 
is unable to cope with the ensuing spike in demand. During normal times, the insur- 
ance company receives about 9,000 calls per week, but during a storm scenario, the 
number of calls per week doubles. 

The claim-to-resolution process model of Cetera is presented in Fig. 7.13. The 
process starts when a call related to lodging a claim is received. The call is routed to 
one of two call centers depending on the location of the caller. Each call center re- 
ceives approximately the same amount of calls (SO—50) and has the same number of 
operators (40 per call center). The process for handling calls is identical across both 
call centers. When a call is received at a call center, the call is picked up by a call 
center operator. The call center operator starts by asking a standard set of questions 
to the customer to determine if the customer has the minimum information required 
to lodge a claim (e.g. insurance policy number). If the customer has enough infor- 
mation, the operator then goes through a questionnaire with the customer, enters all 
relevant details, checks the completeness of the claim and registers the claim. 

Once a claim has been registered, it is routed by the claims handling office, where 
all remaining steps are performed. There is one single claims handling office, so 
regardless of the call center agent where the claim is registered, the claim is routed 
to the same office. In this office, the claim goes through a two-stage evaluation 
process. First of all, the liability of the customer is determined. Secondly, the claim 
is assessed in order to determine if the insurance company has to cover this liability 
and to what extent. If the claim is accepted, payment is initiated and the customer is 
advised of the amount to be paid. The activities of the claims handling department 
are performed by claims handlers. There are 150 claims handlers in total. 

The mean cycle time of each task (in seconds) is indicated in Fig. 7.13. For every 
task, the cycle time follows an exponential distribution. The hourly cost of a call 
center agent is 30, while hourly cost of a claims handler is 50. 

Describe the input that should be given to a simulator in order to simulate this 
process in the normal scenario and in the storm scenario. Using a simulation tool, 
encode the normal and the storm scenarios and run a simulation in order to compare 
these two scenarios. 


7.4.3 Simulation Tools 


Nowadays, most business process modeling tools provide simulation capabilities. 
Examples of tools with simulation support include: ADONIS, ARIS Business De- 
signer, IBM Websphere Business Modeler, OpenText ProVision, Oracle Business 
Process Analysis (BPA) Suite, Savvion Process Modeler, Signavio Process Editor 
and TIBCO Business Studio. The landscape of tools evolves continuously, and thus 
itis very useful to understand the fundamental concepts of process simulation before 
trying to grasp the specific features of a given tool. 

In general, the provided functionality varies visibly from one tool to another. 
For example, some tools allow one to capture the fact that resources do not work 
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continuously, but only during specific periods of time. This is specified by attaching 
a calendar to each resource pool. Some tools additionally allow one to specify that 
new process instances are created only during certain periods of time, for example 
only during business hours. Again, this is specified by attaching a calendar to the 
process model. 

Some of the more sophisticated tools allow one to specify not only branch- 
ing conditions, but also actual boolean expressions that make use of attributes at- 
tached to data objects in the process model. In this way, we can specify for exam- 
ple that a branch coming out of an XOR-split should be taken when the attribute 
“loanAmount” of a data object called “loan application” is greater than 10,000, 
whereas another branch should be taken when this amount is lower than 10,000. 
In this case, the probabilistic distribution of values for the attribute “loanAmount” 
needs to be specified. When the simulator generates objects of type loan, it will give 
them a value according to the probability distribution attached to that attribute. 

There are also small nuances between tools. For example some tools require one 
to specify the mean arrival rate, that is the number of cases that start during one 
time unit (e.g. 50 cases per day), while other tools require one to specify the mean 
inter-arrival time between cases (e.g. one case every 2 minutes). Recall that the 
distinction between mean arrival rate (written A in queueing theory) and mean inter- 
arrival time (1/2) was discussed in Sect. 7.3.1. Other tools go further by allowing 
one to specify not only the inter-arrival time, but how many cases are created every 
time. By default, cases arrive one by one, but in some business processes, cases may 
arrive in batches as illustrated by the following scenario extracted from a description 
of an archival process at the Macau Historical Archives: 


At the beginning of each year, transfer lists are sent to the Historical Archives by various 
organizations. Each transfer list contains approximately 225 historical records. On average 
two transfer lists are received each year. Each record in a transfer list needs to go through 
a process that includes appraisal, classification, annotation, backup, and re-binding among 
other tasks. 

If we consider that each record is a case of this archival process, then we can say that cases 
arrive in batches of 225 x 2 = 450 cases. Moreover, these batches arrive at a fixed inter- 
arrival time of one year. 


Finally, process simulation tools typically differ in terms of how resource pools 
and resource costs are specified. Some tools would only allow one to define a re- 
source pool and define the number of resources in the pool. A single cost per time 
unit is then attached to the entire resource pool. Other tools would allow one to cre- 
ate the resources of a pool one by one and to assign a cost to each created resource 
(e.g. create 10 clerks one by one, each with its name and hourly cost). 

The above discussion illustrates some of the nuances found across simulation 
tools. In order to avoid diving straight away into the numerous details of a tool, it 
may be useful for beginners to take their first steps using the BIMP simulator re- 
ferred to in Example 7.7. BIMP is a rather simple BPMN process model simulator 
that provides the core functionality found in commercial business process simula- 
tion tools. 
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7.4.4 A Word of Caution 


One should keep in mind that the quantitative analysis techniques we have seen in 
this chapter, and simulation in particular, are based on models and on simplifying 
assumptions. The reliability of the output produced by these techniques largely de- 
pends on the accuracy of the numbers that are given as input. Additionally, simula- 
tion assumes that process participants work continuously on the process being sim- 
ulated. In practice though, process participants are not robots. They get distracted 
due to interruptions, they display varying performance depending on various factors, 
and they may adapt differently to new ways of working. 

In this respect, it is good practice whenever possible to derive the input parame- 
ters of a simulation from actual observations, meaning from historical process exe- 
cution data. This is possible when simulating an as-is process that is being executed 
in the company, but not necessarily when simulating a to-be process. In a similar 
spirit, it is recommended to cross-check simulation outputs against expert advice. 
This can be achieved by presenting the simulation results to process stakeholders 
(including process participants). The process stakeholders are usually able to pro- 
vide feedback on the credibility of the resource utilization levels calculated via sim- 
ulation and the actual manifestation of the bottlenecks shown in the simulation. For 
instance, if the simulation points to a bottleneck in a given task, while the stakehold- 
ers and participants perceive this task to be uncritical, there is a clear indication that 
incorrect assumptions have been made. Feedback from stakeholders and participants 
helps to reconfigure the parameters such that the results come closer to matching the 
actual behavior. In other words, process simulation is an iterative analysis technique 
with potentially multiple validation loops. 

Finally, it is advisable to perform sensitivity analysis of the simulation. Con- 
cretely, this means observing how the output of the simulation changes when adding 
one resource to or removing one resource from a resource pool, or when changing 
the processing times by +10 % for example. If such small changes in the simula- 
tion input parameters significantly affect the conclusions drawn from the simulation 
outputs, one can put a question mark on these conclusions. 


7.5 Recap 


In this chapter we saw three quantitative process analysis techniques, namely flow 
analysis, queueing theory and simulation. These techniques allow us to derive pro- 
cess performance measures, such as cycle time or cost, and to understand how differ- 
ent activities and resource pools contribute to the overall performance of a process. 

Flow analysis allows us to calculate performance measures from a process model 
and performance data pertaining to each activity in the model. However, flow anal- 
ysis does not take into account the level of busyness of the resources involved in 
the process, i.e. their level of resource utilization. Yet, waiting times are highly de- 
pendent on resource utilization—the busier the resources are, the longer the waiting 
times. 
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Basic queueing theory models, such as the M/M/1 model, allow us to calculate 
waiting times for individual activities given data about the number of resources and 
their processing times. Other queueing theory models such as queueing networks 
allow us to perform fine-grained analysis at the level of entire processes. However, 
in practice it is convenient to use process simulation for fine-grained analysis. Pro- 
cess simulation allows us to derive process performance measures (e.g. cycle time 
or cost) given data about the activities (e.g. processing times) and data about the 
resources involved in the process. Process simulation is a versatile technique sup- 
ported by a range of process modeling and analysis tools. 


7.6 Solutions to Exercises 


Solution 7.1 


1. There are at least two business processes that need improvement: the quote-to- 
booking process—which starts from the moment a quote is received to the mo- 
ment that a booking is made—and the process for modifying bookings. 

2. The quote-to-book process needs to be improved with respect to cycle time, and 
with respect to error rate. The booking modification process needs improvement 
with respect to error rate. 


Solution 7.2 First we observe that the cycle time of the AND-block is 1. Next, we 
calculate the cycle time of the XOR-block as follows: 0.4 x 1+0.4 x 1+0.2 x 1 
hour. The total cycle time is thus: 1 + 1 + 1 =3 hours. 

Solution 7.3 The cycle time of the process is 2 + 8 + os = 20 days. Assuming 
8 working hours per day, this translates to 160 working hours. The theoretical cycle 
time is 0.5 + 12+ aaa = 20 hours. Hence, cycle time efficiency is 12.5 %. 
Solution 7.4 Little’s law tells us that: CT = WIP/X. At peak time, there are 900 
customers distributed across 6 hours, so the mean arrival rate 2 = 150 customers 
per hour. On the other hand, W/P = 90 during peak time. Thus, CT = 90/150 = 0.6 
hours (i.e. 36 minutes). During non-peak time, 7 = 300/6 = 50 customer per hour 
while WIP = 30, thus CT = 30/50 = 0.6 hours (again 36 minutes). If the number of 
customers per hour during peak times is expected to go up but the WIP has to remain 
constant, we need to reduce the cycle time per customer. This may be achieved by 
shortening the serving time, the interval between the moment a customer enters the 
restaurant and the moment they place an order, or the time it takes for the customer 
to pay. In other words, the process for order taking and payment may need to be 
redesigned. 


Solution 7.5 Given that there are no other costs, we calculate the cost of the process 
by aggregating the resource costs as follows: 0.5 x 25+ 12 x 50+ (4 x 75 +2 x 
100)/(1 — 0.2) = 1237.50. 
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Solution 7.6 On average, 0.05 orders are received per day (A = 0.05), and 0.0625 
orders are fulfilled per day (4 = 0.0625). Thus, the occupation rate of this system 
p =0.05/0.0625 = 0.8. Using the formulas for M/M/1 models, we can deduce that 
the average length of the queue Ly is: 0.87/(1 — 0.8) = 3.2 orders. From there we 
can conclude that the average time an order spends on the queue is W, = 3.2/0.05 = 
64 days. Thus, it takes on average order W = 64 + 16 = 80 working days for an 
order to be fulfilled. 


Solution 7.7 Strictly speaking, we should analyze this problem using an M/M/c 
queueing model. However, the formulas for M/M/c are quite complex to show the 
calculations in detail. Accordingly, we will assume in this solution that the entire call 
center behaves as a single monolithic team, so that we can use an M/M/1 queueing 
model to analyze the problem. Because of this assumption, the results will not be 
exact. 

If we only had seven call center agents, then the occupation rate p = 40/70 = 
0.57, Lg = p7/( — p) = 0.577 /(1 — 0.57) = 0.76, and Wg = Lq/d = 0.76/40 = 
0.0189 hours = 1.13 minutes. So we cannot meet the customer service charter. 

If we can handle 80 calls per hour (eight call center agents), then the occupation 
rate p = 40/80 = 0.5, Lg = p?/(1 — p) =0.57/(1 — 0.5) =0.5, and Wy = Lg /A= 
0.5/40 = 0.0125 hours = 45 seconds, so we meet the customer service charter. 

Ways to reduce costs while staying as close as possible to the customer service 
charter: 


e We could reduce the number of call center agents to 7 and still have an average 
waiting time of 1.13 minutes. That reduces costs by 12.5 % (one call center agent 
less). 

e We could introduce a self-service system, whereby people lodge their application 
online (at least for simple claims). 

e We could extend the call center working times (e.g. work until 6pm or 7pm in- 

stead of 5pm) so that people can call after work, therefore easing the call center 

load during its peak time. 

Reduce the time of each call by providing better training to call center agents. 


Solution 7.8 For this problem, we will reason exclusively in terms of working hours 
as a unit of time, as opposed to calendar hours. We assume that a week consists of 
40 working hours. Calls arrive only during these 40 working hours and call center 
operators and claims handlers work only during these 40 hours. By taking working 
hours as a time unit, we avoid the need to attach calendars resources. 

In the normal scenario (no storm), the arrival rate is 9,000 cases per week, that is 
one case every 16 seconds (this is the inter-arrival time). In the storm scenario the 
inter-arrival time is 8 seconds. In both cases we use an exponential distribution for 
the inter-arrival time. We run simulations corresponding to 5 weeks of work, mean- 
ing 45,000 cases for the normal scenario and 90,000 cases for the storm scenario. 

In order to distinguish between the two call centers, we define two separate re- 
source pools, namely “Call Center Operator 1” and “Call Center Operator 2” each 
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one with 40 resources at an hourly cost of 30, plus a resource pool “Claims Han- 
dler” with 150 resources. We assign tasks to resource pools as indicated in the sce- 
nario and we use the cycle times indicated in the process model as input for the 
simulation. Running the simulation using the BIMP simulator gives us the follow- 
ing outputs. Under the normal scenario, we obtain a resource utilization of around 
53 % for claims handlers and 41 % for call center operators. The average cycle time 
is around 0.5 working hours and the maximum observed cycle time is around 4.4 
working hours. In other words, the resources are under-utilized and thus the cycle 
time is low. 

In the storm season, resource utilization of claims handlers is close to 100 % 
and that of claims handlers (in both claims handling centers) is around 79 %. The 
average cycle time is 12 working hours while the maximum cycle time is around 33 
hours, that is approximately 4 working days. The high resource utilization indicates 
that, in practice, the claims handling office is over-flooded during storm season and 
additional staff are required. On the other hand, the call center has sufficient capacity 
for storm season. The average waiting time for the tasks in the call center is around 
20 seconds. 


7.7 Further Exercises 


Exercise 7.9 Calculate the cycle time, cycle time efficiency and cost of the univer- 
sity admission process described in Exercise |.1, assuming that: 


e The process starts when an online application is submitted. 

e It takes on average 2 weeks (after the online application is submitted) for the 
documents to arrive to the students service by post. 

e The check for completeness of documents takes about 10 minutes. In 20 % of 
cases, the completeness check that some documents are missing. In this cases 
an e-mail is sent to the student automatically by the University admission man- 
agement system based on the input provided by the international students officer 
during the completeness check. 

e A student services officer spends on average 10 minutes to put the degrees and 
transcripts in an envelope and send them to the academic recognition agency. The 
time it takes to send the degrees/transcripts to the academic recognition agency 
and to receive back a response is 2 weeks on average. 

e About 10 % of applications are rejected after the academic recognition assess- 
ment. 

e The university pays a fee of € 5 each time it requests the academic recognition 
agency to accept an application. 

e Checking the English language test results takes 1 day on average, but in reality 
the officer who performs the check only spends 10 minutes on average per check. 
This language test check free. 

e About 10 % of applications are rejected after the English language test. 
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e It takes on average 2 weeks between the time students service sends the copy of 
an application to the committee members and the moment the committee makes 
a decision (accept or reject). On average, the committee spends | hour examining 
each application. 

e It takes on average 2 days (after the decision is made by the academic committee) 
for the students service to record the academic committee’s decision in the Uni- 
versity admission management system. Recording a decision takes on average 2 
minutes. Once a decision is recorded, a notification is automatically sent to the 
student. 

e The hourly cost of the officers at the international students office is € 50. 

e The hourly cost of the academic committee (as a whole) is € 200. 


Exercise 7.10 Let us consider the following process performed by an IT helpdesk 
that handles requests from clients. The clients are employees of a company. There 
are about 500 employees in total. A request may be an IT-related problem that a 
client has, or an access request (e.g. requesting rights to access a system). Requests 
need to be handled according to their type and their priority. There are three priority 
levels: “critical”, “urgent” or “normal”. The current process works as follows. 


A client calls the help desk or sends an e-mail in order to make a request. The help desk is 
staffed with five “Level-1” support staff who, typically, are junior people with less than 12 
months experience, but are capable of resolving known problems and simple requests. The 
hourly cost of a Level-1 staff member is € 40. 

When the Level-1 employee does not know the resolution to a request, the request is for- 
warded to a more experienced “Level-2” support staff. There are three Level-2 staff mem- 
bers and their hourly cost is € 60. When a Level-2 employee receives a new request, they 
evaluate it in order to assign a priority level. The job tracking system will later assign the 
request to the same or to another Level-2 staff depending on the assigned priority level and 
the backlog of requests. 

Once the request is assigned to a Level-2 staff member, the request is researched by the 
Level-2 employee and a resolution is developed and sent back to the Level-1 employee. 
Eventually, the Level-1 employee forwards the resolution to the client who tests the resolu- 
tion. The client notifies the outcome of the test to the Level-1 employee via e-mail. If the 
client states that the request is fixed, it is marked as complete and the process ends. If the 
request is not fixed, it is resent to Level-2 support for further action and goes through the 
process again. 

Requests are registered in a job tracking system. The job tracking system allows help desk 
employees to record the details of the request, the priority level and the name of the client 
who generated the request. When a request is registered, it is marked as “open”. When it 
is moved to level 2, it is marked as “forwarded to level 2” and when the resolution is sent 
back to “Level 1” the request is marked as “returned to level 1”. Finally, when a request 
is resolved, it is marked as “closed”. Every request has a unique identifier. When a request 
is registered, the job tracking system sends an e-mail to the client. The e-mail includes a 
“request reference number” that the client needs to quote when asking questions about the 
request. 


Calculate the cycle time efficiency and the cost-per-execution of the as-is process 
assuming that: 


e Submitting and registering a new request takes 5 minutes on average. 
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e Requests spend on average | hour waiting for a Level-1 staff to check them. This 
applies both to new requests and to re-submitted requests. 

e Checking if a new request is “known” takes on average 10 minutes. In 20 % 
of cases the request is known. In this case, it takes between 2 and 10 minutes 
(average 5 minutes) for the Level-1 staff to communicate the resolution to the 
client. Once this is done, the request is marked as “closed”. On the other hand, if 
the request is not “known”, the request is automatically forwarded to Level 2. 

e New requests spend on average 2 hours waiting for a Level-2 staff to evaluate 
them. Level-2 staff take on average 20 minutes to evaluate a new request. 

e Level-2 staff take 5 minutes to prioritize a request. 

e The time between the moment a request has been prioritized, and the moment the 
request is picked up by a Level-2 staff member is 20 hours. 

e The time required to research and resolve a request is on average 2 hours. 

e The time to write the resolution to a request is on average 20 minutes. 

e Once a Level-2 staff has written the resolution of a request, it takes on average 20 
hours before a the request is fetched from the job tracking system by a Level-1 
staff. 

e It takes on average 20 minutes for a Level-1 staff to send to the client a problem 
resolution previously written by a Level-2 staff. 

e It takes on average 20 hours between the moment a resolution is sent by the 
Level-1 staff, and the moment the resolution is tested by the client. 

e It takes the client around 10 minutes to e-mail the test results to the Level-1 staff. 

e In 20 % of cases the request is not resolved, and it needs to be forwarded to Level- 
2 again. In this latter case, it takes about 2 minutes for the Level-1 to forward the 
request to the Level-2 staff. Unresolved requests that are forwarded in this way 
are automatically marked as prioritized, since they have already been prioritized 
in the previous iteration. 

e There are no other costs besides the resource costs. 


Hint To calculate theoretical cycle time and cost, only take into consideration time 
spent doing actual work, excluding waiting times and handovers. 


Acknowledgement This exercise is inspired by an example developed by Sue Con- 
ger [8]. 


Exercise 7.11 Consider the scenario described in Exercise 7.6. The company in 
question is being pressed by several of its customers to fulfill their orders faster. 
The company’s management estimates that the company stands to lose € 250,000 
in revenue if they do not reduce their order fulfillment time below 40 working days. 
Adding one engineer to the existing team would reduce the time to design a hard- 
ware down to 14 working days (from 16 days). An additional engineer would cost 
the company € 50,000. On the other hand, hiring a second engineering team would 
cost € 250,000. Analyze these two scenarios and recommend an option to the com- 


pany. 
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Fig. 7.14 Mortgage process 


Exercise 7.12 We consider a Level-2 IT service desk with two staff members. Each 
staff member can handle one service request in 4 working hours on average. Service 
times are exponentially distributed. Requests arrive at a mean rate of one request 
every 3 hours according to a Poisson process. What is the average time between the 
moment a service request arrives at this desk and the moment it is fulfilled? 


Exercise 7.13 Consider again the IT helpdesk process described in Exercise 7.10. 
Model and simulate it assuming that cases arrive at a rate of 50 per day according 
to an exponential distribution. Assume that all the activity cycle times follow an 
exponential distribution with the mean (average) given in Exercise 7.10. 


Note When modeling the process, do not model the waiting times between activi- 
ties, only the activities themselves. 


Exercise 7.14 Consider the process model in Fig. 7.14. This model captures a sim- 
plified process for handling applications for mortgages. There are two checks in- 
volved. CT1 deals with a check of the financial coverage of the mortgage appli- 
cation. The second check, CT2, concerns the verification of the property that is to 
be mortgaged. If the result of both checks is positive, the application is accepted 
(task AC). On average, after the execution of task CT1, 20 % of all applications are 
rejected. Meanwhile, task CT2 leads to 30 % of further rejections. If either of the 
checks has an unsatisfactory result, the application is rejected (task AW). The arrival 
process is Poisson, with an average arrival of five cases per hour during business 
hours. For each task, exactly one dedicated resource is available. The processing 
time of every task follows an exponential distribution. The mean processing times 
for tasks CT1, CT2, AC, and AW are, respectively, 5, 4, 3, and 3 minutes. The wage 
of each resource is € 20 per hour. Business hours are from Monday to Friday from 
9am to Spm. Resources are only available during these hours. 


a. Determine the resource utilization of each resource. 
b. Determine the average cycle time of the process. 
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c. Determine the cycle time efficiency of the process. 
d. Determine the average number of mortgage applications that are being handled 
at any given point in time. 


Hint For this exercise, it might be convenient to use a combination of process sim- 
ulation, Little’s law and flow analysis. 


7.8 Further Reading 


The Balanced Scorecard concept alluded to in Sect. 7.1.2 was proposed by Kaplan 
and Norton in 1992 [39] and quickly gained popularity thereafter as a tool to define 
organizational strategy and performance measures. Harmon [31] argues that the tra- 
ditional approach to apply the Balanced Scorecard leads to a bias towards functional 
units (i.e. performance measures are defined for company departments). To address 
this bias, he elaborates an approach to apply the Balanced Scorecard along the pro- 
cess architecture rather than the functional architecture. Fiirstenau [21] gives a more 
detailed overview of approaches to process performance measurement all the way 
from the identification of performance measures using the Balanced Scorecard, to 
their implementation in the context of IT-enabled processes. 

In Sect. 7.2, we showed how flow analysis techniques can be used to calculate 
cycle time and cost. Laguna and Marklund [43] additionally show how to use flow 
analysis to calculate process capacity. Process capacity is the maximum number of 
cases per time unit (e.g. cases per hour) that can be theoretically handled. Another 
possible application of flow analysis is to estimate the error rate of the process, 
meaning the number of cases that will end up in a negative outcome. This latter 
application of flow analysis is discussed for example by Yang et al. [109]. Yang 
et al. also present a technique for flow analysis that is applicable not only to block- 
structured process models but to a much broader class of process models. 

As mentioned in Sect. 7.3, the formula for determining the average queue length 
in the context of the M/M/c model is particularly complicated. Laguna and Mark- 
lund [43, Chap. 6] analyze the M/M/c model (including the formula for average 
queue length) and its application to process analysis. They also analyze the M/M/c/K 
model, where an upper-bound to the length of the queue is imposed (this is param- 
eter K in the model). The M/M/c/K model is suitable for example when there is 
a maximum length of queue beyond which customers are rejected from the queue. 
Adan and Resing [1] give detailed introductions to M/M/1, M/M/c, M/M/c/K and 
other queueing theory models. 

As stated in Sect. 7.4, business process simulation is a versatile approach for 
quantitative process analysis. Numerous case studies illustrating the use of pro- 
cess simulation in various domains can be found in the literature. For example, 
Greasley [24] illustrates the use of business process simulation for redesigning a 
process for road traffic accident reporting. In a similar vein, Van der Aalst et al. [98] 
discuss the use of business process simulation to evaluate different strategies to 
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avoid or to mitigate deadline violations in the context of an insurance claims han- 
dling process in an insurance company. Exercise 7.8 is based on this latter paper. 

Current tools for business process simulation have various limitations. Several 
of these limitations are discussed at length by van der Aalst et al. [99]. One such 
limitation has to do with batching of cases. For example, consider the University 
admissions process described in Exercise 1.1 (p. 4). In this process, each individual 
application progresses independently of other applications, up the point where the 
admissions committee has to assess the application. The committee does not meet 
to handle each individual application, but rather meets at certain times and examines 
a batch of applications. This batching is necessary because it is not practical for the 
committee to meet too often since the committee involves several members with 
busy diaries. Also, the committee needs to compare applications with respect to one 
another, so it only makes sense to meet when either all applications have arrived, 
or a sufficient number of applications have arrived to make comparisons between 
candidates. Let us imagine specifically that the committee meets every 2 weeks but 
only if there are at least 10 applications to be examined. If there are less than 10 
applications, the meeting is skipped and the assessment of pending applications is 
postponed until the next scheduled meeting. Many business process simulation tools 
simply cannot capture this batching behavior. 

To address this and other limitations, Van der Aalst et al. [99] propose to use 
more sophisticated tools for process simulation, namely Discrete-Event Simulation 
(DES) tools. They specifically put forward CPN Tools as a possible DES that can be 
used for business process simulation. CPN Tools is based on Colored Petri Nets—a 
language that extends Petri nets. Other DES tools that can be used for business pro- 
cess simulation include ExtendSim [43] and Arena [40]. For example, Arena is used 
in the aforementioned case study of a road traffic reporting process [24]. DES tools 
are clearly more powerful than specialized business process simulation tools. How- 
ever, the choice of a DES tool means that one cannot directly use a BPMN model for 
simulation. Instead the model has to be re-encoded in another notation. Moreover, 
the use of DES tools requires more technical background from the analyst. These 
trade-offs should be considered when choosing between DES tools and specialized 
business process simulation tools based for example on BPMN. 

We saw throughout the chapter that quantitative analysis techniques allow us to 
identify critical paths and bottlenecks. These are essentially paths and activities in 
the process that require special attention if the goal is to reduce cycle time. Anupindi 
et al. [4] offers detailed advice on how to deal with critical paths and bottlenecks 
in business processes as well as how to reduce waste and repetition. The following 
chapter will discuss some of these insights. 


Chapter 8 
Process Redesign 


We know what we are, but not what we may be. 
William Shakespeare (1564-1616) 


The thorough analysis of a business process typically sparks various ideas and direc- 
tions for redesign. The problem is, however, that redesign is often not approached 
in a systematic way, but rather considered as a purely creative activity. The critical 
point with creative techniques is that parts of the spectrum of potential redesign op- 
tions could be missed. As an alternative, suitable methods can be utilized to yield 
more and, hopefully, better redesign options. 

This chapter deals with rethinking and re-organizing business processes with the 
specific purpose of making them perform better. We clarify the motivation and the 
trade-offs of redesign. Then, we present two methods for systematically redesigning 
processes. First, we introduce Heuristic Process Redesign as a method that builds 
upon an extensive set of redesign options. The method is illustrated by the help of 
a case of a health care institute. Second, we present Product-based Design. This 
method derives a process design based on the composition of a product. 


8.1 The Essence of Process Redesign 


In this section, we describe the motivations and the trade-offs of redesign. We in- 
troduce the Devil’s Quadrangle and discuss options of how redesign can be ap- 
proached. 


8.1.1 Why Redesign? 


As stated, the focus of this chapter is on how to redesign business processes. Be- 
fore explaining this, it is good to reflect on why again it is beneficial at all to focus 
on business processes. Recall that a business process creates and delivers a certain 
product or service that customers are after. If someone would like to improve the 
quality of such a product or service from the perspective of a customer, arguably 
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the best way to do that is to improve the related business process. For example, if 
at some point clients like to make use of a service they purchase from a company 
much earlier than it is able to deliver, it makes sense to think of streamlining the 
business process in question. In that way, a customer-oriented organization is in 
fact a process-centered organization. Business process redesign is all about improv- 
ing the quality of products and services by rethinking and re-organizing business 
processes. 


Question Why would anyone like to redesign business processes? 


One could argue that if a business process has been designed well in the first place, 
then the products and services are already produced in a satisfactory way. Indeed, if 
you can step into a bank or a governmental agency, you can see processes in action 
in ways very similar to how they were introduced there some 50 years ago. This is 
not necessarily a good thing, though. There are at least two reasons why it makes 
sense to consider the redesign of an existing business process, even when it was 
perfectly designed in the first place. The first of these relates to the organic nature 
of organizations. All business processes tend to evolve organically over time. As a 
result, they grow more complex and their performance gradually deteriorates. Some 
common examples of such situations are as follows: 


e At some point, a clerk forgets to carry out a particular quality check. The prod- 
uct was delivered to a client who became really upset because of the unnoticed 
flaws of the product. In response, an extra check is incorporated which involves 
a second clerk to check out whether the quality check is performed at all. This 
works quite well, but after some time the initial quality check becomes automated 
through the introduction of a new production system. The check-on-the-check 
becomes superfluous, but is still part of the process, in this way consuming un- 
necessary resources and time. 

e The marketing department of an organization introduces a special offer for a par- 
ticular type of customers. Each time such a customer engages with this organiza- 
tion, their account managers ask for extra information beyond what is normally 
asked. In this way, the marketing campaign can make a perfectly targeted offer to 
these customers. Yet, the information is not really necessary for the services the 
clients contact this organization in the first place. After some time, the marketing 
campaign has come to and end, but the account managers will still ask for the 
extra information whenever they interact with the particular kind of customer: an 
unnecessary and time-consuming step. 

e An internal auditing department demands at some point that the monetary value 
of certain financial activities are always reported to it, whenever such activities 
are carried out. This cause an extra calculation and an extra reporting step in 
each of the business processes that are affected. Over time, the management of 
the auditing department changes its priorities and starts looking into other, non- 
financial information. The reports, nonetheless, keep coming in. 
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None of the above examples seem so difficult that they cannot be overcome, of 
course. The point is that people who are busy with carrying out day-to-day op- 
erations are usually neither inclined nor equipped to start rethinking the overall 
structure of operations within an organization. Specifically, it is very common for 
people to have a limited insight into why a business process is organized in the 
way it is: People know how to perform their own activities, perhaps some of the 
activities up- and downstream from their position in the process, but certainly not 
much more. Even managers, of whom it can be expected that they take a “heli- 
copter view”, are usually more concerned with day-to-day execution than struc- 
tural improvement. People, it seems, are creatures of habit. A business process per- 
spective helps to overcome the inhibition to improve. So, to fight the troubles that 
go hand in hand with the organical development of a process, redesign is a good 
idea. 

Another reason why it is worthwhile to redesign a business process, even a pro- 
cess that was perfect when it was designed in the first place, is that the world evolves 
as well. New competitors enter the market place that can deliver the same product 
or service that you can, but against lower cost or tailored to a customer’s specific 
needs. The preferences of customers may change too: People may have been will- 
ing to pay a premium for your high-quality product for a long time, but they may 
now prefer a similar product of lower quality that is offered against a considerably 
lower price. Whether it is sensible for an organization to keep on producing a cer- 
tain product or service is not within the scope of this book; that is much more of 
a strategic decision. What we care about are the operations of an organization. So, 
assuming there is a strategic incentive to keep on offering a product or service, busi- 
ness process redesign is the approach to create and deliver it in a more performative 
way. 


Exercise 8.1 Can you identify business processes from your own experience that 
may perhaps have been competitive at some stage, but which seem at this point to 
be unnecessarily complex or outdated given what competitors offer? 


While the two reasons we discussed are important to consider redesigning an 
existing process, the principles behind redesign approaches can also be helpful to 
develop business processes from scratch. For example, in 2002 the Netherlands Au- 
thority for the Financial Markets was set up to regulate behavior on the Dutch fi- 
nancial markets. Many of the business processes it had to start executing had to be 
newly developed. Process redesign principles were applied to find the right balance 
between effectiveness and efficiency. We will still refer to such occasions as pro- 
cess redesign, even though it is technically a misnomer—we would be more precise 
when referring to this situation as process design. We will return to this issue of 
developing processes from scratch when we will be discussing the various types of 
redesign approach. 
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8.1.2 What Is Redesign? 


Let us now take a closer look at what redesign is. If you would follow a broad 
interpretation, any change to an existing process, minor or major, qualifies. Since 
business processes are rather encompassing—they concern among other the steps in 
a process, the workforce that is committed to carrying out the process, the informa- 
tion that is being exchanged, and the information systems employed—this actually 
seems to cover quite a lot. When we talk about process redesign in the context of 
this book, we will not refer to casual or minor updates, or to changes of parts pe- 
ripheral to a process or that have no relation to the business process concept. For 
example, let us suppose that a bank prints the conditions under which a mortgage 
is granted on ordinary paper, and is accustomed to sending the paper work to appli- 
cants when the conditions are completely settled and approved. If the paper type is 
changed into an eco-friendly, recycled alternative, then we would not consider this 
as an act of process redesign. If, on the other hand, the client would be provided at 
any time with an insight into an electronic file that shows the conditions as they are 
developed during the execution of the process, we would be much more confident 
in calling this process redesign, especially if the idea behind it is to improve the 
customer’s experience. 

Rather than trying to pinpoint business process redesign to an exact definition, 
we present a framework that helps to think and reason about the most important 
manifestations of this approach. In this framework, seven elements are identified: 


1. the internal or external customers of the business process 

2. the business process operation view, which relates to how a business process 
is implemented, specifically the number of activities that are identified in the 
process and the nature of each, and 

3. the business process behavior view, which relates to the way a business process 
is executed, specifically the order in which activities are executed and how these 
are scheduled and assigned for execution 

4. the organization and the participants in the business process, captured at two lev- 
els: the organization structure (elements: roles, users, groups, departments, etc.), 
and the organization population (individuals: agents which can have activities 
assigned for execution and the relationships between them) 

5. the information that the business process uses or creates 

. the technology the business process uses, and 

7. the external environment the process is situated in 


fon 


Process redesign, then, is first of all concerned with changing the business pro- 
cess itself, covering both its operational and behaviorial view. Yet, process redesign 
extends to changes that are on the interplay between on the one hand process and on 
the other the organization or even the external environment that the process operates 
in, the information and technology it employs, as well as the products it delivers to 
its customers. This is a comprehensive way of looking at process redesign but it does 
exclude some activities. For example, the way to train people to optimally perform 
new activities they become responsible for is out of scope. 
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Exercise 8.2 Consider the following list and indicate which of these you would 
consider as process redesign initiatives. Motivate your answer and, if applicable, 
provide the links to the elements discussed. 


1. An airline has seen its profits falling over the past year. It decides start a mar- 
keting campaign among its corporate clients in the hope that it can extend its 
profitable freight business. 

2. A governmental agency notices that it is structurally late to respond to citizen’s 
queries. It decides to assign a manager to oversee this particular process and 
mandates her to take appropriate counter actions. 

3. A video rental company sees that its customer base is evaporating. It decides to 
switch to the business of promoting and selling electronic services through which 
clients can see movies on-line and on-demand. 

4. A bank notices internal conflicts between two different departments over the way 
mortgage applications are dealt with. It decides to analyze the role of the various 
departments in the way applications are received and handled to come up with a 
new role structure. 

5. A clinic wants to introduce the one-stop-shop concept to improve over the situ- 
ation that its patients need to make separate appointments for the various diag- 
nostic tests that are part of a procedure for skin cancer screening. 


Not each business domain is equally suitable for the application of business pro- 
cess redesign. To appreciate this, consider the differences between the manufactur- 
ing and services domain. In the manufacturing domain, the emphasis is on trans- 
forming raw materials into tangible products, which often relies on the use of robots 
and sophisticated machinery. It is in the services domain where mostly knowledge 
is involved in the processing of information to deliver a particular service. Compare, 
for example, a car manufacturing company with an insurance company as two char- 
acteristic examples of the respective domains. In general, it is fair to say that for 
service organizations the following properties hold: 


e Making a copy is easy and cheap. In contrast to making a copy of a product 
like a car, it is relatively easy to copy a piece of information, especially if the 
information is in electronic form. 

e There are no real limitations with respect to the in-process inventory. Informa- 
tional products do not require much space and are easy to access, especially if 
they are stored in a database. 

e There are less requirements with respect to the order in which activities are exe- 
cuted: Human resources are flexible in comparison with machines; there are few 
technical constraints with respect to the lay-out of the service process. 

e Quality is difficult to measure. Criteria to assess the quality of a service, an infor- 
mational product, are usually less explicit than those in a manufacturing environ- 
ment. 

e Quality of end products may vary. A manufacturer of goods usually has a min- 
imal number of components that any product should incorporate. However, in 
the services domain it might be attractive to skip certain checks in producing the 
informational product to reduce the workload. 
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e Transportation of electronic data is timeless. In a computer network, information 
travels almost at the speed of light; in a manufacturing environment, the trans- 
portation of parts is an essential share of the total lead-time, for example think of 
parts and sub-assemblies that have to be moved from one plant to the other. 


From these differences, it is clear that there are more degrees of freedom for 
redesigning business process in the services domain, than is the case in the manu- 
facturing domain. To optimize a manufacturing process, one has to look for oppor- 
tunities while juggling many physical constraints. For example, parts that have to be 
assembled must be transported to the same physical location; by contrast, pieces of 
information can be put together while they are physically stored on different loca- 
tions. Similarly, where logistics has evolved as a field to deal with the inventory of 
parts and half-products, the storage of (digital) information is usually a no-brainer. 
Business process redesign, therefore, is at this point mostly applicable in the ser- 
vices domain. Since there is a trend that manufacturing and high-tech organizations 
are increasingly making money with providing services along with their physical 
products, it can be expected that process redesign will become of greater impor- 
tance here as well. 


Exercise 8.3 Consider the following processes and decide whether they are suit- 
able for being redesigned. Use the properties that distinguish the manufacturing and 
services domain as a mental checklist to support your choice. 


Dealing with a customer complaint. 

Carrying out cardiovascular surgery. 

The production of a wafer stepping machine. 
Transporting a package. 

Providing financial advice on composing a portfolio. 
Designing a train station. 
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8.1.3 The Devil’s Quadrangle 


So far, we have not been overly specific about the goals behind redesign. Clearly, 
it is about making a business process perform better, but we have not discussed the 
available directions for improvement. 


Question What do we want to achieve exactly when a process is redesigned? 


A framework that helps answering this question is the Devil’s Quadrangle, which is 
depicted in Fig. 8.1. This framework is based on the four performance dimensions 
discussed in Chap. 7, namely time, cost, quality and flexibility. Ideally, a business 
process redesign decreases the time required to handle a case, it lowers the required 
cost of executing the process, it improves the quality of the service delivered, and 
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Fig. 8.1 The Devil’s 
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it increases the ability of the business process to deal with variation. The interest- 
ing property of this framework is how it expresses that improving a process in one 
dimension may have a weakening effect on another. For example, one may decide 
to add a reconciliation activity to a business process to improve the quality of the 
delivered service. Yet, this may backfire on the timeliness of the service delivery. 
The ominous name of the framework refers to the difficult trade-offs that sometimes 
have to be made. Awareness of these trade-offs is utterly important for effective 
process redesign. 


Exercise 8.4 Consider the following redesign acts. Which performance measures 
are affected by these, either positively or negatively? 


1. A new computer application is developed that speeds up the calculation of the 
maximum loan amount that a given client can be offered. 

2. Whenever a quote is needed from a financial provider, a clerk must use a direct 
messaging system instead of e-mail. 

3. By the end of the year, additional, temporary workers are hired and assigned to 
picking items for fulfilling Christmas orders. 


While the performance dimensions of the Devil’s Quadrangle are helpful to think 
of the desired effects of business process redesign in general and for a particu- 
lar business process in particular, they are also useful to think about common ap- 
proaches to improve business processes. We will devote more attention to this topic 
when dealing with different types of process redesign approach; we will then refer 
to them as redesign heuristics. 


8.1.4 How to Redesign? 


There is a great variety of books on process redesign. These deal, among other top- 
ics, with different methodologies, present case studies, advance success factors and 
management lessons. Since the supply may be a bit overwhelming, the following 
classification may help to see the forest for the trees. 

There are three levels of abstractions for methods with respect to process re- 
design: methodologies, techniques, and tools. 
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A methodology, the highest level of abstraction, is defined as a collection of 
problem-solving methods governed by a set of principles and a common philoso- 
phy for solving targeted problems. This is primarily the field of consulting firms 
which developed proprietary methodologies, which stretch out from the early anal- 
ysis phase of a redesign project until the implementation and after care. 

At the next level of abstraction, a technique is defined as a set of precisely de- 
scribed procedures for achieving a standard task. Some oft-encountered techniques 
for process analysis—one of the phases in a redesign project—are e.g., fishbone di- 
agramming, Pareto analysis, and cognitive mapping (see Chap. 6). To support the 
activity of redesigning, creativity techniques like out-of-box-thinking, affinity di- 
agramming, and the Delphi method (brainstorm) are available. For the modeling 
and evaluation of business processes, techniques are in use as flowcharting, IDEF, 
speech act modeling, data modeling, activity-based costing, time motion studies, 
Petri nets, role-playing, and simulation. 

At the lowest, most concrete level a tool is defined as a computer software pack- 
age to support one or more techniques. The majority of what some would call pro- 
cess redesign tools are actually process modeling tools. A large number of tools is 
also available for the evaluation of business process models, in particular supporting 
the technique of simulation (see Chap. 7). Fewer tools are available to structurally 
capture knowledge about the redesign directions or to support existing creativity 
techniques. Tools are often presented as “intelligent” or “advanced”, although hardly 
any of those actively design business processes. 

Our concern in this chapter is foremost with redesign methodologies. Now, if 
you would take the effort to consider all the existing ones you will find that they 
are usually very specific about preliminary steps in a process redesign project, e.g. 
the assembly of the project team, and similarly specific towards the end, e.g. how to 
evaluate a new business process. They are not specific, however, on how to take an 
existing process and turn it into a better performing one. In other words, the tech- 
nical challenge of process redesign is an underdeveloped area. An apt observation 
that we encountered on this phenomenon is provided by Alec Sharp and Patrick 
McDermott: 


How to get from the as-is to the to-be [in a process redesign project] isn’t explained, so 
we conclude that during the break, the famous ATAMO procedure is invoked (“And Then, 
A Miracle occurs’’). 


This part of the chapter provides concrete guidance for the technical challenge of 
process redesign. The two methodologies that we will describe are rather different. 
To see what distinguishes them it is important to understand the generic traits of 
process redesign methodologies. Generally speaking, such methodologies can differ 
with respect to their intensity and their starting point. 

The intensity of a methodology refers to the pace that one aims with changing 
the process. Here, we can distinguish between what are commonly referred to as 
revolutionary and evolutionary levels. Process redesign was originally positioned 
as an approach that would aim for a radically different outcome, in other words: a 
revolution. However, methodologies that aim for a more incremental approach have 
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become much more popular. The latter kind would, obviously, qualify as aiming for 
an evolutionary intensity. 

The other distinguishing point is the starting point of the redesign effort. One 
can (a) start from scratch, (b) from the traits of the existing process that is to be 
redesigned, or (c) from a good, general design, also known as a reference model. 
We will deal with these one by one. 


Option (a): Historically, process redesign would follow a clean slate approach: the 
existing process would be completely abandoned and new ways of producing 
a particular product or service would be developed. It is for good reason that 
Michael Hammer, one of the gurus behind process redesign famously quipped: 
“Obliterate, don’t automate.” There are certain advantages to such an approach: 
It is much easier to get rid off the inefficiencies that have crept into the process 
by organic growth (see our earlier discussion). Also, the potential to come up 
with some truly innovative process alternative is in this way better exploited. 

Option (b): Over the course of time, however, it has become a far more popular 
approach to closely look at the existing process. The reason behind this is that it 
turned out to be extremely hard to develop a complete process from scratch, in 
particular to cover all exceptions, to not forget any steps, and to add the required 
level of detail. 

Option (c): The newest development is to start work from a blueprint or refer- 
ence model. Such standard solutions are typically developed by consultancy and 
IT companies as representing the state-of-the-art on how to do purchasing, hire 
someone, or deal with complaints. The IT infrastructure library (ITIL) is a good 
example of such a solution, as it incorporates practical guidelines on how to do 
problem and incident management within service organizations. The promise of 
starting from a blueprint is that it will give an up-to-date and standardized view 
on how to carry out a business process. 


Overseeing the landscape of process redesign methodologies, it is fair to say 
that using the existing process as a starting point has become at this point the most 
popular approach, followed by the use of a reference model. Building on either 
the existing design or a reference design, local updates are then identified, each of 
which contribute a gradual improvement of performance in comparison with the 
starting situation. Radical approaches are still being applied. In general, clean sheet, 
revolutionary approaches tend to be more risky as they break away from existing, 
known procedures. Yet, they also tend to deliver higher benefits if they succeed. 
After all, inefficiencies can be completely rooted out. 

In the remainder of this chapter, we will deal with two different methodologies, 
which represent two extreme variants of the spectrum. First of all, we will discuss 
a methodology that is based on so-called redesign heuristics, which starts from an 
existing process to achieve gradual performance improvement. The second method- 
ology is called Product-Based Design; this approach starts from a blank sheet of 
paper to come up with a radically improved process design. The two methods will 
give a fairly good idea of mainstream process redesign and at the same demonstrate 
how redesign methodologies can fundamentally differ. 
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8.2 Heuristic Process Redesign 


We will now discuss the main stages in the methodology of Heuristic Process Re- 
design. Since there is an overlap between the activities that have been described in 
other chapters, we will focus on the technical challenge of generating a new process 
design and provide pointers to other parts of the book here. We will first outline the 
stages and then turn to its most important ingredient in more detail, i.e. the redesign 
heuristics that we mentioned earlier. 


1. Initiate: In the first stage, the redesign project is set up. There are various orga- 
nizational measures that have to be taken, e.g. setting up the project team, but 
from a technical perspective the most important goals are: (a) to create an under- 
standing of the existing situation (as-is) and (b) to set the performance goals for 
the redesign project. For (a), the modeling techniques that have been discussed 
in Chaps. 3 and 4 are useful, as well as the analysis techniques explained in 
Chaps. 6 and 7 to gain an understanding of performance issues, bottlenecks, and 
improvement opportunities. To come up with a clearer picture on (b), the Devil’s 
Quadrangle that has been discussed in this chapter is a great asset. 

2. Design: Given the outcomes of the initiate stage, the design stage makes use of 
a fixed list of redesign heuristics to determine potential improvement actions on 
the existing process. For each of the heuristics that is being considered, it needs 
to be determined whether it is at all applicable and, if so, what a desirable action 
is. A redesign heuristics is desirable to apply if it helps to attain the desired per- 
formance improvement of the process under consideration. After consideration 
of each of the redesign heuristics, it makes sense to see which clusters of appli- 
cable and desirable heuristics can be created. While for some of the heuristics it 
may make sense to be applied together, for others this is not the case. For exam- 
ple, if you decide to automate a certain activity, it makes no sense to empower the 
resource that initially carried out that activity. In this way, a set of scenarios can 
be generated, each of which describes which redesign heuristics are applied in 
this scenario and, very importantly, how this is done. For example, if the heuris- 
tic to automate an activity is applied it needs to be specified which activities are 
subjected to it. The scenarios, therefore, should be seen as alternatives for the 
process redesign. 

3. Evaluate: This is the stage where the different redesign scenarios as developed 
in the previous stage need to be evaluated. This evaluation can be done in a qual- 
itative way, e.g. employing the techniques from Chap. 6, or in a quantitative way, 
see Chap. 7. In many practical settings, a combination of the two is used where 
a panel of experts assesses the attractiveness of the various scenarios and where 
simulation studies are used to underpin the choice for one particular scenario 
to develop further, potentially all the way to implementing it. An outcome of the 
evaluation stage may also be that none of the scenarios seems attractive to pursue 
or even powerful enough to establish the desirable performance improvement. 
Depending on the exact outcome, the decision may be to adjust the performance 
goals, to step back to the design stage, or to drop the redesign project altogether. 
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The description of the stages are here described as separate ones, but in practice 
they will be executed in highly iterative and overlapping ways. We will now focus 
the discussion of the methodology to the redesign heuristics. A redesign heuris- 
tic can be seen as a rule of thumb for deriving a different process. Many of the 
heuristics we present suggest a particular action to take, while others merely indi- 
cate the dimension along which a business process can be changed. The heuristics 
we present here are all based on historic redesign projects, where they were applied 
successfully to generate redesign scenarios. 

We explained that improving a process is related to the elements we described in 
Sect. 8.1.2. Thus, we classify the redesign heuristics in a similar way. We identify 
redesign heuristics that are oriented towards the seven elements we discussed above: 
customers, business process operation, business process behavior, organization, in- 
formation, technology, and external environment. Note that this distinction is not 
mutually exclusive. Therefore, some redesign heuristics could actually be assigned 
to more than one of these classes. 


8.2.1 Customer Heuristics 


Heuristics in this category focus on improving the interaction with customers. They 
focus on control relocation, contact reduction, and integration. 


Control relocation: “Move controls towards the customer’. Different checks and 
reconciliation operations that are part of a business process may be moved to- 
wards the customer. Consider the example of Pacific Bell that moved its billing 
controls towards its customers, in this way eliminating the bulk of its billing er- 
rors. It also improved customer satisfaction. A disadvantage of moving a control 
towards a customer is higher probability of fraud, resulting in less yield. 

Contact reduction: “Reduce the number of contacts with customers and third par- 
ties”. The exchange of information with a customer or third party is always time- 
consuming. Especially when information exchanges take place by regular mail, 
substantial wait times may be involved. Also, each contact introduces the pos- 
sibility of an error injection. Imagine a situation where the multitude of bills, 
invoices, and receipts creates a heavy reconciliation burden. Reducing the num- 
ber of contacts may in such a case decrease throughput time. Note that it is not 
always necessary to skip certain information exchanges, but that it is possible 
to combine them with limited extra cost. A disadvantage of a smaller number 
of contacts might be the loss of essential information, which is a quality issue. 
Combining contacts may result in the delivery or receipt of too many data, which 
involves cost. 

Integration: “Consider the integration with a business process of the customer or 
a supplier”. This heuristic can be seen as exploiting the supply-chain concept 
known from production. The actual application of this heuristic may take on 
different forms. For example, when two parties have to agree upon a product 
they jointly produce, it may be more efficient to perform several intermediate 
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Table 8.1 Characteristics of 


the customer heuristics Time Cost Quality Flexibility 


Control relocation . = + 
Contact reduction + _ + 
Integration + + . = 


reviews than performing one large review after both parties have completed their 
parts. In general, integrated business processes should render a more efficient 
execution, both from a time and cost perspective. The drawback of integration is 
that mutual dependence grows and therefore, flexibility may decrease. 


Using the dimensions of the Devil’s Quadrangle introduced earlier, a summary 
of the general effects of the three customer heuristics is shown in Table 8.1. This 
table shows that a heuristic can be generally expected to have a positive effect (+), 
a negative effect (—) or a neutral effect (-) on any of the dimensions of the Devil’s 
Quadrangle. Note that a positive effect on the cost dimension, as can be expected 
from the Integration heuristic, means that cost actually goes down. 


Exercise 8.5 Explain the + sign for the contact reduction heuristic with respect to 
the time dimension. 


8.2.2 Business Process Operation Heuristics 


Business process operation puts the focus on the elements of a business process. 
There are five heuristics relating to case types: activity elimination, case-based work, 
triage, and activity composition. 


Case types: “Determine whether activities are related to the same type of case and, 
if necessary, distinguish new business processes”. One should be cautious of 
parts of business processes that are not specific for the business process they 
are part of. Ignoring this phenomenon may result in a less effective management 
of such a subflow and a lower efficiency. Applying this heuristic may result in 
faster processing times and less cost. Yet, it may also result in more coordina- 
tion problems between the business process (quality) and less possibilities for 
rearranging the business process as a whole (flexibility). 

Activity elimination: “Eliminate unnecessary activities from a business process”. 
A common way of regarding an activity as unnecessary is when it adds no value 
from a customer’s point of view. Typically, control activities in a business process 
do not do this; they are incorporated in the model to fix problems created (or not 
elevated) in earlier steps. Control activities can often be identified by iterations 
in a process. The redundancy of an activity can also trigger activity elimination. 
The aims of this heuristic is to increase the speed of processing and to reduce the 
cost of handling an order. An important drawback may be that the quality of the 
service deteriorates. 
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Table 8.2 Characteristics of 
the business process 
operation heuristics 


Time Cost Quality Flexibility 


Case types = 


Activity elimination 


Case-based work + = 


Triage . — + = 


Activity composition : = 


Case-based work: “Consider removing batch-processing and periodic activities 
from a business process”. Some notable examples of disturbances in handling 
a single case are (a) that the case becomes piled up in a batch and (b) that the 
case is slowed down by periodic activities, e.g. because processing depends on 
a computer system that is only available at specific times. Getting rid of these 
constraints may significantly speed up the handling of individual cases. On the 
other hand, efficiencies of scale can be reached by batch processing which are 
reversed by this heuristic. Also, the cost of making information systems perma- 
nently available may be costly. 

Triage: “Consider the division of a general activity into two or more alternative 
activities”. Through this heuristic, it is possible to design activities that are better 
aligned with the capabilities of resources and the characteristics of the cases be- 
ing processed, which improves quality. On the other hand, specialization in gen- 
eral makes a process less flexible and may decrease the efficiency of work. An 
alternative form of the triage heuristic is to divide an activity into similar instead 
of alternative activities for different subcategories of the cases being processed. 
For example, a special cash desk may be set up for customers with an expected 
low processing time. Note that the triage heuristic can be seen as a translation of 
the case types heuristic on an activity level. 

Activity composition: “Combine small activities into composite activities and di- 
vide large activities into workable smaller activities”. Composing larger activi- 
ties should result in the reduction of setup times, i.e., the time that is spent by 
a resource to become familiar with the specifics of a case. By executing a large 
activity which used to consist of several smaller ones, a positive effect may also 
be expected on the quality of the delivered work. On the other hand, making 
activities too large may result in (a) smaller run-time flexibility and (b) lower 
quality as activities become unworkable. Both effects are exactly countered by 
dividing activities into smaller ones. Obviously, smaller activities may also result 
in longer set-up times. This heuristic is related to the triage heuristic in the sense 
that they both are concerned with the division and combination of activities. 


The assessment of the heuristics that aim at the business process operation is 
summarized in Table 8.2. The meaning of the signs is the same as in the previ- 
ous table. For example, case-based work can be expected to be highly beneficial in 
the time dimension; triage may boost the quality of a process. Note that only one 
manifestation of the activity composition heuristic is shown, i.e. the case that large 
activities are composed of smaller ones. 


266 8 Process Redesign 


8.2.3 Business Process Behavior Heuristics 


Business process behavior regulates the logic within the business process. There are 
four heuristics for this category, namely resequencing, parallelism, knock-out, and 
exception. 


Resequencing: “Move activities to more appropriate places”. In existing business 
processes, actual activity orderings often do not reveal the necessary dependen- 
cies between activities. Sometimes it is better to postpone an activity if it is not 
required for its immediate follow-up activities. The benefit would be that perhaps 
its execution may prove to become superfluous, which saves cost. Also, an activ- 
ity may be moved into the proximity of a similar activity, in this way diminishing 
set-up times. This heuristic is also known as process order optimization. 

Parallelism: “Consider whether activities may be executed in parallel”. The obvi- 
ous effect of placing activities in parallel is that throughput time may be consid- 
erably reduced. The applicability of this heuristic in business process redesign is 
large. In practical settings, activities are often ordered sequentially without the 
existence of hard logical restrictions prescribing such an order. A drawback of in- 
troducing more parallelism in a business process that incorporates possibilities of 
knock-outs is that the cost of business process execution may increase. Also, the 
management of business processes with concurrent behavior can become more 
complex (flexibility). 

Knock-out: “Order knock-outs in an increasing order of effort and in a decreas- 
ing order of termination probability”. A typical element of a business process is 
the subsequent checking of various conditions that must be satisfied to deliver a 
positive end result. Any condition that is not met may lead to a termination of 
that part of the business process: the knock-out. If there is freedom in choosing 
the order in which the various conditions are checked, the condition that has the 
most favorable ratio of expected knock-out probability versus the expected effort 
to check the condition should be pursued. Next, the second best condition, and 
so forth. This way of ordering checks yields on average the least costly busi- 
ness process execution. Implementing this heuristic may result in a (part of a) 
business process that takes a longer throughput time than a full parallel checking 
of all conditions. The knock-out heuristic is a specific form of the resequencing 
heuristic. 

Exception: “Design business processes for typical cases and isolate exceptional 
cases from the normal flow”. Exceptions may seriously disturb normal opera- 
tions. An exception will require workers to get acquainted with the specifics of 
the exception even though they may not be able to handle it. Setup times are then 
wasted. Isolating exceptions may possibly increase the overall performance as 
specific expertise can be build up by workers working on the exceptions, even 
though this may come at a cost. A drawback is that the business process will 
become more complex, possibly decreasing its flexibility. 


The assessment of the heuristics that target the behavior of the business process 
can be seen in Table 8.3. Again, the meaning of the signs is similar to those in 
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Table 8.3. Characteristics of 
the business process behavior 
heuristics 


Time Cost Quality Flexibility 


Resequencing 


Parallelism + _ : = 


Knock-out _ + 


Exception “+f = + = 


earlier tables. Note how the exception heuristic stands out with respect to improving 
the quality dimension. 


8.2.4 Organization Heuristics 


Organization refers to two categories of heuristics. The first set relates to the struc- 
ture of the organization (mostly the allocation of resources). There are seven heuris- 
tics in this category, namely case assignment, flexible assignment, centralization, 
split responsibilities, customer teams, numerical involvement, and case manager. 


Case assignment: “Let workers perform as many steps as possible for single 
cases”. By using case assignment in the most extreme form, for each activity 
execution the participant is selected who has worked on the case before—if any. 
The obvious advantage of this heuristic is that this person will have become ac- 
quainted with the case and will need less set-up time in carrying out subsequent 
activities. An additional benefit may be that the quality of service is increased: 
the participant knows exactly what the specifics of the case are. On the nega- 
tive side, the flexibility of work allocation is seriously reduced. The execution 
of a case may experience substantial queue time when the person to whom it is 
assigned is not available, nullifying expected time gains. 

Flexible assignment: “Assign work in such a way that maximal flexibility is pre- 
served for the near future”. Suppose that an activity can be executed by either 
of two available participants, then the heuristic suggests to assign it to the most 
specialized person. In this way, the likelihood to commit the free, more general 
resource to another work package is maximal. The advantage of this heuristic is 
that an organization stays flexible with respect to assigning work and that over- 
all queueing time is reduced: it is less probable that the execution of a case has 
to wait for the availability of a specific resource. Another advantage is that the 
workers with the highest specialization can be expected to take on most of the 
work, which may result in a higher quality. The disadvantages of applying this 
heuristic can be subtle. For example, work load may become unbalanced, re- 
sulting in less job satisfaction. Also, possibilities for specialists to evolve into 
generalists are reduced. These are both quality concerns. In certain situations, 
specialists may even be more expensive to carry out work. 

Centralization: “Treat geographically dispersed resources as if they are central- 
ized”. This heuristic is explicitly aimed at exploiting the benefits of a Business 
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Process Management System or BPMS for short (see Chap. 9). After all, when a 
BPMS takes care of assigning work to resources it becomes less relevant where 
these resources are located geographically. In this sense, this heuristic can be 
seen as a special form of the integral technology heuristic (see later in this chap- 
ter). The specific advantage of this measure is that resources can be committed 
more flexibly, which gives a better utilization and possibly a better throughput 
time. The introduction of a BPMS and training of the workforce may, of course, 
be substantial. 

Split responsibilities: “Avoid shared responsibilities for tasks by people from dif- 
ferent functional units”. The idea behind this heuristic is that activities for which 
different departments share the responsibility are more likely to be a source of 
neglect and conflict. Reducing the overlap in responsibilities should lead to a 
better quality of activity execution. Also, a higher responsiveness to available 
work may be developed, so that customers are served quicker. On the other hand, 
applying this heuristic may reduce the effective number of resources that is avail- 
able for a work item. This may have a negative effect on its throughput time, as 
more queuing may occur, and the organization becomes less flexible. 

Customer teams: “Consider to compose work teams of people from different de- 
partments that will take care of the complete handling of specific sorts of cases”. 
Depending on its exact desired form, the customer team heuristic may be im- 
plemented by the case assignment heuristic. On the other hand, a customer team 
may involve more workers with the same qualifications, in this way relaxing the 
strict requirements of the case assignment heuristic. Advantages and disadvan- 
tages are similar to those of the case assignment heuristic. In addition, working 
as a team may improve the attractiveness of the work, which is a quality aspect. 

Numerical involvement: “Minimize the number of departments, groups and per- 
sons involved in a business process”. Applying this heuristic may lead to less 
coordination problems. Less time spent on coordination makes more time avail- 
able for the processing of cases. Reducing the number of departments may lead 
to less split responsibilities, with similar pros (quality) and cons (flexibility) as 
the split responsibilities heuristic discussed before. Note that smaller numbers 
of specialized units may prohibit the build up of expertise (a quality issue) and 
routine (a cost issue). 

Case manager: “Appoint one person to be responsible for the handling of each 
type of case, the case manager”. The case manager is responsible for a specific 
order or customer. Note that a case manager is not necessarily someone who 
works on the actual case and even if the person does, not exclusively so. The 
difference with the case assignment practice is that the emphasis is on manage- 
ment of the process—not its execution. The most important aim of the heuristic 
is to improve upon the external quality of a business process. The business pro- 
cess will become more transparent from the viewpoint of a customer: the case 
manager provides a single point of contact. This, in general, positively influ- 
ences customer satisfaction. It may also have a positive effect on the internal 
quality of the business process, as someone is accountable for and committed to 
correcting mistakes. Obviously, the assignment of a case manager has financial 
consequences as capacity must be devoted to this job. 
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Table 8.4 Characteristics of 
the organization structure 
heuristics 


Time Cost Quality Flexibility 


Case assignment : . + = 


Flexible assignment + - : sib 


Centralization + = i 4 
Split responsibilities : . Af = 
Customer teams . i ae _ 


Numerical involvement 4 


Case manager : — + 


The assessment of the heuristics that target the side of the organizational structure 
involved in a business process can be seen in Table 8.4. 

The second set relates to the organizational population and the resources being 
involved in terms of type and number. This category includes three heuristics: extra 
resources, specialist-generalist, and empower. 


Extra resources “If capacity is insufficient, consider increasing the available num- 
ber of resources”. This is straightforward heuristic, which aims at extending ca- 
pacity. extending the capacity to handle cases, in this way reducing queue time. It 
may also help to implement a more flexible assignment policy. Of course, hiring 
or buying extra resources has its cost. Note the contrast of this heuristic with the 
numerical involvement heuristic. 

Specialist-generalist “Consider to deepen or broaden the skills of resources”. Par- 
ticipants in a process may be turned from specialists into generalists or the other 
way around. A specialized resource can be trained to gain more qualifications. 
A generalist, on the other hand, may be assigned to the same type of work for 
a longer period of time, so that skills in this area deepen while other qualifica- 
tions become obsolete. In the context of designing an entirely new business pro- 
cess, the application of this heuristic comes down to considering the specialist- 
generalist ratio of new hires. Clearly, specialists build up routine more quickly 
and may have more profound knowledge in an area than generalists have. As a 
result, they work more quickly and deliver higher quality. On the other hand, the 
availability of generalists adds more flexibility to the business process and can 
lead to a better utilization of resources. Depending on the degree of specializa- 
tion or generalization, either type of resource may be more costly. Note that this 
heuristic differs from the triage concept in the sense that the focus is not on the 
division of activities. 

Empower “Give workers most of the decision-making authority instead of relying 
on middle management”. In traditional business processes, substantial time may 
be spent on authorizing the outcomes of activities that have been performed by 
others. If workers are empowered to take decisions autonomously, this may result 
in smoother operations with lower throughput times. The reduction of middle 
management from the business process also reduces the labor cost spent on the 
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Table 8.5 Characteristics of 
the organization population 
heuristics 


Time Cost Quality — Flexibility 


Extra resources + _ . ah 


Specialist-generalist = + : + = 


Empower + : = + 


processing of cases. A drawback may be that the quality of the decisions is lower 
and that obvious errors are no longer identified. If bad decisions or errors result 
in rework, the cost of handling a case may actually increase compared to the 
original situation. 


The assessment of the heuristics for the organization population can be seen in 
Table 8.5. Note that for the specialist-generalist heuristic, the general effects are 
included of investing into more specialized skills of the workforce. Clearly, investing 
in generalists gives the opposite effect. 


8.2.5 Information Heuristics 


The information category describes redesign heuristics related to the information the 
business process uses, creates, may use or may create. It includes control addition 
and buffering. 


Control addition: “Check the completeness and correctness of incoming materials 
and check the output before it is sent to customers”. This heuristic promotes the 
addition of controls to a business process. Such additions may lead to a higher 
quality of the business process execution. Obviously, an additional control will 
require time, which may be substantial, and absorbs resources. Note the contrast 
between the intent of this heuristic and that of the activity elimination heuristic 
discussed earlier. 

Buffering: “Instead of requesting information from an external source, buffer it 
and subscribe to updates”. Obtaining information from other parties is a time- 
consuming part in many business processes. By having information directly 
available when required, throughput times may be substantially reduced. This 
heuristic can be compared to the caching principle that microprocessors apply. 
Of course, the subscription fee for information updates may be costly. This is 
certainly so if we consider information sources that contain far more information 
than is ever used. Substantial cost may also be involved with storing all the in- 
formation. Note that this heuristic is a weak form of the integration heuristic that 
is yet to be discussed. 


A summary of the general effects of the two information heuristics are shown in 
Table 8.6. 
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Table 8.6 Characteristics of 


the information heuristics Time Cost Quality Flexibility 


Control addition t 
Buffering + = 


Table 8.7 Characteristics of 


the technology heuristics Cost Quality Time Flexibility 


Activity automation + = + = 


Integral technology + = 


8.2.6 Technology Heuristics 


This category describes redesign heuristics related to the technology the business 
process uses or may use. It includes activity automation and integral technology. 


Activity automation: “Consider automating activities”. A particularly positive re- 
sult of automating activities may be that activities can be executed faster and 
with a more predictable result. An obvious disadvantage is that the development 
of a system that performs an activity may be very costly. Generally speaking, a 
system performing an activity is also less flexible in handling variations than a 
human resource. Instead of fully automating an activity, it may also be consid- 
ered to provide automated support to a resource executing an activity. 

Integral technology: “Try to elevate physical constraints in a business process by 
applying new technology”. In general, new technology can offer all kinds of pos- 
itive effect. For example, the application of a BPMS may result in less time that 
is spent on routing (electronic) work. A Document Management System, in its 
turn, will open up to all participants the information available on cases. This 
may result in a better quality of service. New technology can also change the 
traditional way of doing business by giving participants completely new oppor- 
tunities. The purchase, development, implementation, training, and maintenance 
efforts related to technology obviously incur costs. In addition, new technology 
may instill workers with apprehension, which may decrease the quality of the 
business process. 


The two technology heuristics can be characterized as is shown in Table 8.7. 


8.2.7 External Environment Heuristics 


The external environment category contains heuristics that try to improve upon the 
collaboration and communication with the third parties. These include trusted party, 
outsourcing, and interfacing. 
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Table 8.8 Characteristics of 
the external environment 
heuristics 


Cost Quality Time Flexibility 


Trusted party . = 


Outsourcing . = 


Interfacing + : + = 


Trusted party: “Instead of determining information oneself, use the results of a 
trusted party”. Some decisions or assessments that are made within a busi- 
ness process are not specific to that process. Other parties may have deter- 
mined the same information in another context, which—if it were available— 
could replace the decision or assessment. An example is the creditworthiness 
of a customer that bank A wants to establish. If a customer can present a re- 
cent creditworthiness certificate of bank B, then bank A may be likely to ac- 
cept it. Obviously, the trusted party heuristic reduces cost and may even cut 
back throughput time. On the other hand, the quality of the business process 
becomes dependent upon the quality of some other party’s work. Some co- 
ordination effort with trusted parties is also likely to be required, which di- 
minishes flexibility. This heuristic is different from the buffering heuristic, 
because the business process owner is not the one obtaining the informa- 
tion. 

Outsourcing: “Consider outsourcing a business process completely or parts of it”. 
Another party may be more efficient in performing the same work, so it might as 
well perform it for one’s own business process. The obvious aim of outsourcing 
work is that it will generate less cost. A drawback may be that quality decreases. 
Outsourcing also requires more coordination efforts and will make managing the 
business process more complex. Note that this heuristic differs from the trusted 
party heuristic. In the case of outsourcing, an activity is executed at run time 
by another party. The trusted party heuristic allows for the use of a result in the 
(recent) past. 

Interfacing: “Consider a standardized interface with customers and partners”. The 
idea behind this heuristic is that a standardized interface diminishes the oc- 
currence of mistakes, incomplete applications, or unintelligible information ex- 
changes. So, a standardized interface may result in less errors (quality) and faster 
processing (time). However, by standardizing the interface it becomes impossi- 
ble to deal with exceptional situations (flexibility). The interfacing heuristic can 
be seen as a specific interpretation of the integration heuristic, although it is not 
specifically aimed at customers. 


The characteristics of the external environment heuristics are summarized in Ta- 
ble 8.8. This concludes the description of the various heuristics. In what follows, we 
will be looking at their application. 
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8.3 The Case of a Health Care Institution 


At this point, we will consider a realistic case of a healthcare institute (see Fig. 8.2). 
The case concerns the Intake process for elderly patients with mental problems, 
which is styled after the way this is carried out in the Eindhoven region. The Intake 
process starts with a notice by telephone at the secretarial office of the healthcare 
institute. This notice is done by the family doctor of the person who is in need of 
mental treatment. The secretarial worker inquires after the name and residence of 
the patient. On basis of this information, the doctor is put through to the nursing 
officer responsible for the part of the region that the patient lives in. 

The nursing officer makes a full inquiry into the mental, health, and social status 
of the patient in question. This information is recorded on a registration form. After 
this conversation had ended, this form is handed in at the secretarial office of the 
institute. Here, the information on the form is stored in the information system and 
subsequently printed. For new patients, a patient file is created. The registration 
form as well as the print from the information system are stored in the patient file. 
Patient files are kept at the secretarial office and may not leave the building. At the 
secretarial office, two registration cards are produced for, respectively, the future 
first and second intaker of the patient. The registration card contains a set of basic 
patient data. The new patient is added on the list of new notices. 

Halfway during each week, on Wednesday, a staff meeting of the entire medical 
team takes place. The medical team consists of social—-medical workers, physicians, 
and a psychiatrist. During this meeting, the team leader assigns all new patients on 
the list of new notices to members of the team. Each patient will be assigned to 
a social—medical worker, who will act as the first intaker of the patient. One of the 
physicians will act as the second intaker. In assigning intakers, the team leader takes 
into account their expertise, the geographical region they are responsible for, earlier 
contacts they might have had with the patient, and their case load. The assignments 
are recorded on an assignment list which is handed to the secretarial office. For 
each new assignment, it is also determined whether the medical file of the patient is 
required. This information is added to the assignment list. 

The secretarial office stores the assignment of each patient of the assignment list 
in the information system. It passes the produced registration cards to the first and 
second intaker of each newly assigned patient. An intaker keeps this registration at 
times when visiting the patient and being at the office. For each patient for which 
the medical file is required, the secretarial office prepares and sends a letter to the 
family doctor of the patient, requesting for a copy of the medical file. As soon as 
this copy is received, the secretarial office will inform the second intaker and add 
the copy to the patient file. 

The first intaker plans a meeting with the patient as soon as this is possible. 
During the first meeting, the patient is examined using a standard checklist which 
is filled out. Additional observations are registered in a personal notebook. After a 
visit, the first intaker puts a copy of these notes in the file of a patient. The standard 
checklist is also added to the patient’s file. 

The second intaker plans the first meeting only after the medical information of 
the physician—if required—has been received. Physicians use dictaphones to record 
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their observations made during meetings with patients. The secretarial office types 
out these tapes, after which the information is added to the patient file. 

As soon as the meetings of the first and second intaker with the patient have 
taken place, the secretarial office puts the patient on the list of patients that reach 
this status. For the staff meeting on Wednesday, they provide the team leader with a 
list of these patients. For each of these patients, the first and second intaker together 
with the team leader and the attending psychiatrist formulate a treatment plan. This 
treatment plan formally ends the intake procedure. 

What we will now do is discuss three alternatives to the process, which all 
have been generated using the heuristics discussed so far. In other words, each 
design is derived from the existing process by the application of one or more re- 
design heuristics at appropriate places. To guide the derivation of these designs, we 
will assume that bringing back the cycle time of this process is the main objec- 
tive. 


8.3.1 Sending Medical Files by Post 


A considerable part of the cycle time in the Intake process is consumed by the wait 
time for the medical file to arrive by post. On basis of the integration and technology 
heuristics we consider the alternative that medical files become available on-line to 
the mental health care institute. (In practice, this should presumably be restricted to 
read-only access for patients that are indeed reported to the mental health-care in- 
stitute.) Note that this alternative presupposes a considerable usage of technology: 
doctors should store their patient information electronically and communication fa- 
cilities should be installed as well. 

By the direct availability of the medical file, the “Ask for medical file” activity 
in Fig. 8.2 is replaced by the “Access medical file” activity, which is performed by 
the secretarial office. Probably, roughly the same time that was spent on preparing 
and sending a request letter will be required for accessing and printing the patient 
file. The “Update client file” activity stays in place, but it is not triggered anymore 
by the “Medical file”. The wait time for the medical file is now completely reduced, 
which favorably influences the cycle time. 


8.3.2 Periodic Meetings 


As part of the Intake process, the staff meeting is planned at regular weekly intervals, 
on Wednesdays. During a staff meeting two important things take place: 


1. for new cases, the first and second intakers are assigned, and 
2. for cases for which both intake interviews have taken place, treatment plans are 
determined 
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From a process perspective, periodic restrictions on activities seem odd. Let us 
assume that an additional analysis of the Intake process points out that the first 
activity does not really require a meeting context, provided that the team leader 
has sufficient information on the criteria used for new assignments. Admittedly, 
the second activity is indeed best performed in the context of a meeting. This is 
because of the limited availability of the psychiatrists, which prohibits more flexible 
measures. 

On basis of the case-based work heuristic, we consider as an alternative to the 
existing process that the team leader will carry out new case assignments as soon 
as they are due; the weekly meeting is strictly used for determining treatment plans. 
The process in Fig. 8.2 then changes in the sense that the “Wednesday morning” 
event is removed. Because the information is available to the team leader for taking 
assignment decisions, it can be expected that the original duration of the activity 
decreases. This time includes the report of the assignment to the secretarial office. 
Both the social—medical worker and the physician will no longer spend this time on 
the case. The cycle time of an average case will drastically drop, on average by 2.5 
working days—half a working week—as this is the expected time a new case has to 
wait before it is assigned (assuming a uniform distribution of cases over the week). 


8.3.3 Requesting Medical Files 


For each new case, a decision has to be made whether the medical file of the patient 
will be requested. This request is made to the family doctor. It should be noted that 
the family doctor is also the one who notifies the new case at the initiation of the 
process. This raises the question whether the contact reduction heuristic may be 
applicable. Closer inspection of the routing of individual cases shows that in 95 % 
of all new cases the medical file is requested for. This extremely high figure certainly 
justifies consideration of the exception heuristic. After all, not requiring the medical 
information seems to be the exception. 

A combined application of the contact reduction heuristic, the exception heuris- 
tic and the resequencing heuristic leads to an alternative process design where the 
secretarial office directly asks for the medical file after the family doctor makes con- 
tact with the mental health care institute. Also, the routine is dropped to determine 
for each case at a staff meeting whether medical information is required. The new 
process design is shown in Fig. 8.3. 

Note that in this case, the exception heuristic coincides with the secondary inter- 
pretation of the triage heuristic. What used to be an alternative activity, asking for 
medical information, has become a general part of the process. As a result, the cycle 
time is sharply reduced. 

This ends the explanation of Heuristic Process Redesign. While this method- 
ology still involves a fair dose of creativity and skills, the availability of redesign 
heuristics helps to more easily generate new designs. Each time the heuristics are 
used, it makes sense to consider which sets of heuristics are applicable by taking the 
redesign goals into account. 
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Exercise 8.6 Consider the three redesign scenarios that were discussed previously. 
As explained, these scenarios focus on the reduction of cycle time of the process in 
question. Can you explain how the other performance dimensions are affected by 
these scenarios? 


8.4 Product-Based Design 


The methodology of Product-based Design is very different from Heuristic Process 
Redesign. First of all, it aims at radically rethinking how a particular product or 
service can be created instead of using an incremental approach as we saw before. 

Secondly, not so much the existing process is the starting point of the redesign. 
Rather, the characteristics of the particular product that the process-to-be is expected 
to deliver are used to, in fact, reason back what that process should look like. Think 
of it in this way: if you like to produce a red, electronic vehicle on four wheels, you 
are certain that the process to produce it at some stage must involve the production 
or purchase of a chassis, that there is a step needed to assemble four wheels to that 
chassis, that you will need to insert a battery at some point, and that you will need 
to paint the vehicle (if you cannot get your hands on red parts, that is). You are 
perhaps not sure in what order these things need to take place exactly, but you can 
at least identify some logical dependencies. For example, you are better off painting 
the vehicle after you acquired the chassis. 

The idea behind Product-based Design is that by ignoring the existing process 
to create a particular product it becomes feasible to develop the leanest, most per- 
formative process possible. While Product-based Design is more ambitious than 
Heuristic Process Redesign, it is also more limited in its application scope: It has 
been specifically developed to design processes that produce informational prod- 
ucts, e.g. a decision, a proposal, or a permit. It is this informational product that is 
analyzed and laid down in a product data model. There is a striking resemblance 
between this model and the bill-of-material (BOM) as used in the manufacturing 
domain. The product data model is subsequently used by the designer to determine 
the best process structure to create and deliver that product. Given that there are, in 
general, multiple ways to produce an informational product, Product-based Design 
discloses all of these. 

After this brief introduction, we will now outline the steps of Product-based De- 
sign. The most important stages are: 


1. Scoping: In this initial phase the business process is selected that will be subject 
to the redesign. The performance targets for this process are identified, as well 
as the limitations to be taken into consideration for the final design. 

2. Analysis: A study of the product specification leads to its decomposition into 
information elements and their logical dependencies in the form of a product 
data model. The existing business process—if any—is diagnosed to retrieve data 
that are both significant for designing the new business process and for the sake 
of evaluation. 
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3. Design: Based on the redesign performance objectives, the product data model, 
and (estimated) performance figures, one or more process designs are derived 
that best match with the design goals. 

4. Evaluation: The process designs are verified, validated with end-users, and their 
estimated performance is analyzed in more detail. The most promising designs 
can be presented to the commissioning management to assess the degree in which 
objectives can be realized and to select the most favorable design to be imple- 
mented. 


These phases are presented in a sequential order, but in practice it is often desir- 
able that iterations will take place. For example, the evaluation phase is explicitly 
aimed at identifying design errors, which may result in rework on the design. The 
focus of the remainder of this section will be on the analysis and design phases. The 
purpose is not to treat all the details of this method, but to give the reader an idea 
of the approach, its main artifacts, and how it is different from Heuristic Process 
Redesign. 


8.4.1 Analysis: Creating a Product Data Model 


In the analysis phase, all distinguished materials that may be relevant sources on the 
characteristics of the product to-be-delivered are analyzed. The purpose is to iden- 
tify information elements, their dependencies, and the processing logic involved, i.e. 
how existing information can be combined to create new information. For a proper 
representation of this information, we will be using a tree-like structure that we will 
refer to as a product data model. This structure is different from the traditional BOM 
found in manufacturing, which is due to several differences between informational 
products and physical products. These differences lead to two important updates of 
the traditional BOM. First, the same piece of information may be used to manufac- 
ture various kinds of new information. Therefore, also non-tree-like structures are 
possible. For example, the age of an applicant for a life insurance may be used to 
estimate both (a) the involved health risks for that patient and (b) the risks of work 
related accidents. Secondly, there are no physical constraints to produce an infor- 
mational product and therefore there are typically multiple ways to derive a piece 
of information. For example, health risks may be estimated using either a patient 
questionnaire or a full medical examination of that patient. 

At this point, we present a graphical example of a product data model, as shown 
in Fig. 8.4. 

All nodes in this figure correspond to information elements that may be used to 
decide whether some candidate is suitable to become a helicopter pilot in the Dutch 
Air force. We will refer to this model throughout the remainder of this section as the 
helicopter pilot product data model . Arcs are used to express the dependencies be- 
tween the various pieces of information, i.e. the information elements. The meaning 
of the information elements is as follows: 
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Fig. 8.4 The helicopter pilot 
product data model © 


A: suitability to become a helicopter pilot. 

B: psychological fitness. 

C: physical fitness. 

D: latest result of suitability test in the previous two years. 
E: quality of reflexes. 

F: quality of eye-sight. 


Each incoming arc of a node signifies an alternative way of determining a value 
for the corresponding information element for a specific case. If outgoing arcs of 
multiple nodes are joined, this means that values of all of the corresponding infor- 
mation elements are required to determine a value for the information element the 
arrow leads to. There are also information elements which have incoming arrows 
that do not origin from other information elements. These relate to those elements 
that do not rely on the values of other information elements, e.g. element B. We will 
refer to such information elements as leaf elements. 

One of the things that is expressed in Fig. 8.4 is that there are three ways to 
determine a value for information element A. The suitability of a candidate (a) can 
be determined on the basis of: 


1. the combined results of the psychological test (B) and the physical test (C) 
2. the result of a previous suitability test (D), or 
3. the candidate’s eye-sight quality (F’) 


The way in which a new piece of information is determined on the basis of one 
or more pieces of other information is called a production rule or an operation. In 
reality, different production rules may be applicable under different conditions. It 
may be the case that a pilot’s eye-sight is extremely bad (F’), which directly gives 
as a result that the candidate is not suitable (A). However, in a more common case, 
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the eye-sight quality is one of the many aspects that are incorporated in a physical 
test (B), which should be combined with the outcome of the psychological test (C) 
to determine the suitability result (A). Also, not for each candidate that applies to 
become a pilot any previous test result (D) will be available—quite the contrary. 
But if there is one of a recent date, it can be used directly. 

From the helicopter pilot product data model it becomes clear how the depen- 
dencies between data may be used to derive a favorable design. For example, if the 
target is to minimize the cost it may be wise to check first whether there is a pre- 
vious test result and next to check the eyes of the candidate. Only if these checks 
do not lead to rejecting the candidate, a full examination is additionally required. 
Obviously, the expected cost of all these activities really determine whether this is a 
good design. 

In practice, when analyzing materials that cover the product specification, it is a 
good idea to distinguish the top information element first. Examples of typical top 
elements are: 


e fora banking process: the decision whether a loan should be granted to a company 
and, if so, under which conditions and for which amount. 

e for aclaim process of a social security agency: the decision whether an applicant 
should receive an unemployment allowance and if so for what reasons, for which 
period, and for which amount. 

e for an intake process of an insurance company: the decision whether a family can 
be accepted as the holders of a health insurance policy. 


Using the top element as the desired end result, it is a logical exercise to identify 
the information that can be used to directly render a value for the top information 
element. Obviously, this approach can be repeated for the newly found information 
elements. 

Instead of such a top-down analysis, it may at times be more attractive to start at 
the beginning of the existing process, for example by analyzing application forms, 
complaint forms, and request forms that are in use to start the process. This is cer- 
tainly feasible, but it bears the risk of the inclusion of superfluous information ele- 
ments in the product data model. In a practical application of Product-based Design 
for a Dutch bank, we compared a posteriori the amount of information that was orig- 
inally obtained in the business process and the information that was obtained in the 
final design. This comparison showed that almost 30 % of the originally obtained 
information was superfluous. 

Another issue is how to pick the right information elements in a product data 
model. The following aspects are relevant for this choice: 


1. an information element is too large if different parts of it are used in different 
production rules; the information element should be broken up to enable the 
application of production rules without determining irrelevant information. 

2. information elements should not be necessarily associated with their physical 
manifestation, nor is it necessary that physical information carriers have an in- 
formation element counterpart (avoid information elements like “intake form” or 
“computer screen output’). 
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3. information elements may be atomic, for example a name or a credit score, or 
composite. Examples for the latter are: all members of a family, a listing of all the 
requested products with their characteristics, or an overview of all the payment 
conditions that are in effect. The type of a composite information element is 
composed type, e.g. a set of numerals, free text, or a Boolean value. 


Exercise 8.7 The following is an excerpt of the stipulations of a Dutch bank con- 
cerning medium length business loans: 


The funds for a medium length loan that is made available to a client but which is not 
withdrawn by the client must be placed on the money market. If the funding cost of the 
loan is higher than the rewards of the temporary placing, this difference is the basis for the 
monthly disposal provision. The disposal provision amounts to half of this difference with a 
minimum of 1/12 % per month. The disposal provision should be part of the loan proposal. 


Develop a product data model. Consider the “loan proposal” as the top informa- 
tion element. You may leave out the production rules for this exercise. 


The next step in completing the product data model is describing as accurately 
as possible the involved production rules. All the production rules that relate to 
a specific product data model are referred to as its production logic. The step to 
determine the production logic may either follow up on the complete identification 
of all production rules, or may take place as soon as a new production rule has been 
distinguished. The production logic specifies how the value of an output information 
element may be determined on the basis of the values of its inputs. Note that some 
of the inputs may not be used in every calculation, but required for specific cases or 
to test constraints. The description of production logic may be given in pseudo code 
or another rather precise specification language. For example, using the helicopter 
pilot product data model again: The production rule that relates to the use of a value 
for F to determine a value for A may be: “If a candidate’s vision of either or both 
eyes as expressed in diopters is above +0.5 or below —0.5, then such a candidate is 
considered as unsuitable to become a helicopter pilot’. 


Exercise 8.8 In the helicopter pilot product data model, there are two additional 
ways to determine someone’s suitability to become a helicopter pilot beyond the 
one that was just mentioned. Provide sample production rules for both of these. 
Indicate separately under which conditions they are applicable. 


The most important criteria on any language for the purpose of specifying the 
production logic are expressiveness and clarity. A representation of the production 
logic for each production rule is valuable for at least four reasons: 


1. Writing out the full specification is a direct validation on the distinguished in- 
puts of the involved production rule: forgotten inputs or bad data types can be 
detected. 

2. An analysis of the production logic is relevant for the estimation of performance 
characteristics when actually determining information with this production rule: 
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labor and computer cost, speed, accuracy, etc. These characteristics are useful— 
as will be shown—in designing the workflow. 

3. A representation of production logic that is of an algorithmic nature can be used 
as a functional specification for the information system that can execute this pro- 
duction rule. This is an important stepping stone for system development activi- 
ties that may follow up the workflow redesign. 

4. If the production logic is not totally algorithmic, it is likely that a human operator 
must execute it in practice. Then, the production logic is of use to develop task 
instructions for these operators. 


The most accurate descriptions of production logic can be given when it involves 
an exact algorithm. In such a case, we will speak of a formal production rule. How- 
ever, the production of many information elements in office settings is often not 
or not completely formal. It may be relevant, required or even the only option that 
a human passes a judgment without following a totally formalized decision mak- 
ing process. A typical example of such a non-formal production rule would involve 
the question whether some one is responsible for one’s own discharge. If there is a 
dispute, opposite explanations of different parties must be taken into account. A hu- 
man expert may be called in to determine the plausibility of these explanations, as 
there are no known algorithms to do this. Another example is whether the purchase 
of some good is ethically admissible, which is a relevant piece of information in 
determining whether a loan should or should not be granted for this purpose. This 
decision may suppose a value system that is hard to describe formally. 

If a production rule is not of a formal nature it is important to at least check if all 
the required inputs are identified. Also, as noted before, describing as precisely as 
possible how the output must be produced on the basis of its inputs is a valuable step 
in determining working instructions for non-formal production rules. These work- 
ing instructions can be provided to the people who will actually be responsible for 
determining the involved information in practice, that is to say: when the designed 
process is put into production. These rules may very well signal where Knowledge 
Management Systems can be beneficial. 


Exercise 8.9 Consider an issue-to-resolution process (see Chap. 1). Determine two 
information elements that are important to provide a value for in this process, one 
of which involves a formal production rule and the other which is not. 


Although a complete univocal procedure may not exist for a production rule, it 
is often the case that under specific circumstances this decision is completely for- 
mal. For example, in determining whether someone qualifies for an unemployment 
allowance it is relevant to determine what the usual pattern of labor hours for this 
person was during a week. In special cases, someone’s actual labor pattern may be 
whimsical, e.g. due to a combination of different jobs or seasonal labor. So, deter- 
mining the usual pattern is best done in those cases by using human interpretation. 

However, if the applicant has a steady pattern of working hours for a long pe- 
riod of time, e.g. eight hours per day within one job, from Monday to Friday over 
the last five years, determining the usual labor pattern is straightforward and can be 
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described formally. Another example is the authorization function that must be per- 
formed to determine whether a loan proposal may be sent to a client. Generally, this 
function is a matter of human judgment, which must take a large number of factors 
into account. On the other hand, if the loan sum is small, the client is a known client 
with sufficient coverage, and the purchasing goal is standard, the proposal may be 
acceptable with no further inspection. 

When all information elements, their inter-dependencies and the production logic 
have been described, a final analysis step follows. This last step is required to iden- 
tify all the characteristics that are relevant to design a business process that is effi- 
cient in terms of cost, reliability, or speed. The final analysis step consists of three 
steps, which we will describe here only briefly: 


Source analysis The source analysis is aimed at identifying the sources of all the 
leaf elements in the product data model, i.e. the ones that do not rely on other in- 
formation elements. Typically, multiple sources are available to obtain the same 
piece of information. For example, a record of historical grants of unemploy- 
ment allowances may be obtained directly from an applicant or from the agencies 
that have provided these allowances in the past. Another example is somebody’s 
payable debt position. In Europe, a bank may obtain this information from dif- 
ferent scoring agencies (e.g. Experian, Equifax, Schufa, BKR). Different ways of 
obtaining information may have different characteristics. A client may be very 
willing to self-report information about credit positions, but this information may 
not be very reliable. Similarly, local authorities may provide correct domestic 
information at a very low cost, but their response time may be considerable. 
Depending on the criteria that are identified in the scoping phase, it is wise to 
first identify the possible sources for each leaf element and subsequently score 
them on relevant points of comparison. Assuming general performance goals like 
improving efficiency, bringing back throughput time while maintaining (or im- 
proving) an existing quality level, relevant points of comparison for each leaf are: 
cost of obtaining it, delivery speed of the information, availability of the specific 
information and reliability of the provided information. 

Production analysis The production analysis focuses on the identified production 
rules with the aim to estimate the involved cost, speed, and quality of producing 
the new information. As there may be different ways to obtain a piece of infor- 
mation, similarly different production rules typically exist for the same piece of 
information. Designing the process is for a large part concerned with selecting 
the right set and the right execution order of production rules given a set of per- 
formance targets. From these targets it becomes clear which optimization criteria 
are prevailing. For example, suppose that an important performance target aims 
at a reduction of the labor cost. If there are two rule for the same piece of infor- 
mation, the one that takes the least amount of time is the one may be preferred. 
After all, the formal production rule may be automated. Obviously, this efficiency 
gain should be set off against the cost and time, which is involved with develop- 
ing the software. It should be noted here that the production analysis is a very 
time-consuming part of the analysis phase, even more so when there is a poor 
tradition of operations measurement within the company at hand. The time that 
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should be invested in obtaining reliable information should be balanced against 
the desired reliability of the quality estimates of the process design. 

Fraction analysis The fraction analysis involves a study of the distribution of in- 
formation element values. As we already explained, an information element may 
carry specific values. For example, the value of the information element “travel 
insurance required” may be either yes or no. The figures on the likelihood of in- 
formation elements taking on specific values may be very relevant to design an 
efficient process. In combination with the figures from the production analysis 
(cost, speed, etc.), favorable orderings of executing production rules may be de- 
termined. For example, suppose that there are two production rules for the same 
information element with different applicability domains, with very different in- 
put elements, but with a similar cost structure to obtain values for them. In such a 
case, it may be wise from a cost perspective to aim at executing the rule with the 
widest applicability first. Only if this production rule does not yield an outcome, 
applying the other rule may be tried. 


As has become clear, each of the separate analyzes are useful for deciding on the 
actual design of the to-be business process. Note that the steps not necessarily need 
to be executed in the order they are described here. The heart of the matter is that the 
results of these analyzes together provide a good basis for the actual act of process 
design. 


8.4.2 Design: Deriving a Process from a Product Data Model 


In this part, we will consider how a product data model can be used to derive a 
process design. For that purpose we will refer again to the helicopter pilot product 
data model. When developing a process design, we will allow for the creation of 
an activity for each information element in the product data model. Such an activ- 
ity is concerned with creating a value for that information element according to a 
particular production rule. If the need is there, more than one activity for each infor- 
mation element may appear. Such duplicates, for example, can help to improve the 
readability of a process model that describes the process design. 

Activities may only be incorporated in a process model in a way such that the 
dependencies between the information elements in the product data model are re- 
spected. That means that an information element can only be created by invoking a 
corresponding activity if the process design ensures that the required values for its 
inputs elements may have become available. So, for example, if we like to create 
an activity that produces a value for element X on the basis of a production rule 
that requires input values for Y and Z, the process design should ensure that values 
for Y and Z are created before this new activity is initiated. A process design that 
is generated with Product-based Design in such a way is called correct. Note that 
activities for creating values for leaf elements may be inserted at any stage: They do 
not require inputs after all. 
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Fig. 8.5 An incorrect process design for the helicopter pilot product data model 
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Fig. 8.6 A correct process design for the helicopter pilot product data model 


Consider the process models that are depicted in Figs. 8.5 and 8.6. They represent 
alternative process designs. Both designs include an activity that is involved with 
the creation of information element A. In Fig. 8.5 it can be seen that the “Create A” 
activity will be invoked after the creation of information element B, which is created 
in parallel to the successive creation of values for E and C. However, the product 
data model in Fig. 8.4 shows no production rule for creating a value for C on the 
basis of E alone. Yet, there is a production rule that shows how the combined use 
of E and F can be used for that, but in this design no value for F is determined 
before the creation of a value for C. The design in Fig. 8.5 is, therefore, not correct. 

Compare this design with the one in Fig. 8.6. Here, all creation activities are 
either producing values for leaf elements in the product data model (F, F, B) or 
create values for information elements on basis of production rules for which the in- 
puts are created by preceding activities (C, A). The design in this figure is, therefore, 
correct. 
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Fig. 8.7 An alternative process design for the helicopter pilot product data model 


Exercise 8.10 Consider the process design that is visualized in Fig. 8.7. Is this a 
correct process design? Motivate your answer. 


The second important criterion to be taken into consideration for a process de- 
sign that is generated with Product-based Design is called completeness. A process 
design may or may not cover all the information elements that have been identified 
in a product data model. If a process design covers all information elements in a 
given product data model we will call it complete. Consider the designs in Figs. 8.5, 
8.6, and 8.7. None of these designs cover the creation of a value for D, even though 
D is part of the product data model that these designs refer to. We therefore say that 
these designs are not complete. 

Leaving out the creation of values for information elements from a process design 
may be a deliberate choice. In such a case, leaving out D inhibits the potential 
determination of a value for A using the production rule that has D as an input. 
It may very well be that on the basis of the analysis of data, the process designer 
deliberately decided not to include this option. This would make sense in a situation 
where very few applicants try to re-apply to become a helicopter pilot. After all, 
including this option may complicate the design, but not add much value in practical 
terms. On the other hand, the designer may have overseen this option overall, which 
explains why it is useful to check for completeness. 


Exercise 8.11 Develop a complete process design on the basis of helicopter pilot 
product data model and capture that design as a process model. 


Note that a process design that is complete with respect to information elements 
may still not exploit all available production rules. Without exact information on 
which production rules are used for which creation activities, though, this may be 
hard to determine. Clearly, it may be important for designers to check in practical 
applications of Product-based Design whether they have exploited all the opportu- 
nities that a product data model provides. 
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We can impose other quality criteria on process designs and many of these criteria 
can be extracted from more widely applicable ones. For example, we often like to 
capture a process design in the form of a sound process model, see Chap. 5.4.1. 

At this point, we consider as a more important issue the performance of the 
process that is designed with Product-based Design. We mentioned that during the 
scoping phase of a project, the performance criteria are to be established for the pro- 
cess in question. One of the most important trade-offs is whether the design should 
result in a fast process versus an efficient process. A fast process can be designed 
by exploiting the opportunities to work in parallel. This may, however, not at all be 
an efficient process. Given that, in general, there may be different ways to establish 
a value for the same information element, a parallel process potentially induces too 
much work to be done. A more efficient way of carrying out a process would be to 
do as little work as possible, prioritize less costly yet effective activities, and only 
refer to alternatives if absolutely necessary. Note how these two different perspec- 
tives coincide with the parallelism and knock-out redesign heuristics we discussed 
earlier in this chapter. 


Exercise 8.12 Develop a complete process design on the basis of helicopter pilot 
product data model and capture it as a process model. The design should involve a 
cost-efficient process. You may assume that the production rules to create a value 
for A on the basis of D or F are rather, just as the creation of values for the leaf ele- 
ments. The use of the production rule for A that has B and C as inputs is, however, 
much more expensive. 


While many other performance criteria can be taken into account when applying 
Product-based Design, we will not deal with them at this place. It is important to 
realize that a more sophisticated notion of performance will also assume more de- 
tailed information to be available. For example, if it is important to design a secure 
process it is important to understand the risks that are involved with obtaining or 
creating values for information elements. 


8.5 Recap 


In this chapter, we discussed the motivation for process redesign. The Devil’s Quad- 
rangle helped us to clarify that many redesign options have to be discussed from the 
perspective of a trade-off between time, cost, quality, and flexibility. Redesign can 
be approached as a purely creative activity or using a systematic technique. In this 
chapter, we focus on two of such systematic approaches, namely Heuristic Process 
Redesign and Product-based Design. 

The methodology of Heuristic Process Redesign involves the phases of initia- 
tion, design, and evaluation. Various heuristics are available to support the design 
phase. They focus on the seven areas being related to processes, including cus- 
tomers, business process operations, business process behavior, organization, infor- 
mation, technology, and the external environment. We studied the application of 
some the heuristics in the case of a health care institution. 
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As an alternative method, we discussed a product-based design approach. The 
idea is to use a decomposition model of the product as a starting point, and infer 
options on what the process model for constructing the product could look like. 
Central to this method is the analysis and specification of the product data model. 
The actual design can then be tuned to the desirable performance characteristics of 
the process. 


8.6 Solutions to Exercises 


Solution 8.1 This is a hands-on exercise. A potential to approach this question 
might be to think of companies that offered services which are now provided by 
other companies via the internet. 


Solution 8.2 


1. “An airline has seen its profits falling over the past year. It decides to launch a 
marketing campaign among its corporate clients in the hope that it can extend its 
profitable freight business”: Not a redesign initiative, no link to process. 

2. “A governmental agency notices that it is structurally late to respond to a citi- 
zen’s queries. It decides to assign a manager to oversee this particular process 
and to take appropriate counter actions”: Redesign refers to participants and the 
business process itself. 

3. “A video rental company sees that its customer base is evaporating. It decides 
to switch to the business of promoting and selling electronic services through 
which clients can see movies on-line and on-demand”: Not so much a process 
redesign initiative; although there is certainly a link to process and products, this 
is much more a strategic initiative. 

4. “A bank notices internal conflicts between two different departments over the 
way mortgage applications are dealt with. It decides to analyze the role of the 
various departments in the way applications are received and handled to come 
up with a new role structure”: A redesign initiative touches on process and par- 
ticipants. 

5. “A clinic wants to introduce the one-stop-shop concept to improve over the sit- 
uation that its patients need to make separate appointments for the various diag- 
nostic tests that are part of a procedure for skin cancer screening”: A redesign 
initiative touches on process and customers. 


Solution 8.3 


1. Dealing with a customer complaint: Suitable. 

2. Carrying out cardiovascular surgery: Mildly suitable, there are physical con- 
straints involved here. 

3. The production of a wafer stepping machine: Not very suitable, highly physical 
process. 
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4. Transporting a package: Mildly suitable, there are physical constraints involved 
here. 

5. Providing financial advice on composing a portfolio: Suitable. 

6. Designing a train station: Suitable. 


Solution 8.4 Consider the following redesign acts. Which performance measures 
are affected by these, either positively or negatively? 


1. “A new computer application is developed that speeds up the calculation of the 
maximum loan amount that a given client can be offered”: Time is positively 
affected, development of the application may be costly. 

2. “Whenever a clerk wants to have a quote from a financial provider, the clerk 
must use a direct messaging system instead of e-mail’: Quality and time may be 
positively influenced since the feedback is obtained directly and may be more 
to the point. Quality may also be negatively affected, depending on the kind of 
feedback this interaction generates. 

3. “By the end of the year, additional, temporary workers are hired and assigned 
to picking items for fulfilling Christmas orders”: This provides more flexibility 
which may also be exploited to improve timeliness. It is clearly a costly affair and 
temporary workers may deliver lower quality since they are less familiar with the 
operations. 


Solution 8.5 The + sign signifies a positive development with respect to the time 
dimension. Since process redesign is in general concerned with speeding up the 
process, a positive contribution necessarily relates to bringing back the time in terms 
of, for example, cycle time or service time. In the case of the contact reduction 
heuristic, the most likely scenario is that the time is reduced that is related to waiting 
for responses of customers or third parties. This explains the + sign. 


Solution 8.6 This is a hands-on exercise. What is important is to identify under 
which assumptions positive or negative impacts can be expected. 


Solution 8.7 The product data model is shown in Fig. 8.8. The meaning of the 
labels of the information elements is as follows: 


1. LP: The loan proposal, the top element. Within the limits of the provided text, 
this is the ultimate piece of information that can be established. 

2. DP: The disposal provision. This is the single element that is being mentioned in 
the given text as the information that must be included in the loan proposal. 

3. FC: The funding cost of the loan. It is this information element that must be 
compared with rtp, the next element. 

4. RTP: The rewards of the temporary placing. This piece of information is to be 
compared with fc. The disposal provision is based on this comparison. 

5. MP: The minimum percentage. This is actually a constant, which is used under 
certain conditions. 
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Fig. 8.8 Solution for the loan 
proposal (i) 


Solution 8.8 Production rule 1. To determine the value for A on the basis of B 
and C: “If both the psychological fitness and physical fitness of the candidate are 
considered excellent, then the candidate can be considered as suitable to become a 
helicopter pilot’. 

Production rule 2. To determine the value for A on the basis of D: “If the earlier 
test result indicated that a candidate was unsuitable to become a helicopter pilot, 
then the candidate is (still) considered as unsuitable to become a helicopter pilot’. 

Production rule | is always applicable. Production rule 2 is only applicable if the 
candidate has undergone a previous suitability test. 


Solution 8.9 Information element 1: Issue class. This information element provides 
the severity of the issue that a client brings forth. It can be conceived as an infor- 
mation element that results from a formal production rule, where an employee must 
use a weighted evaluation formula to determine this severity. 

Information element 2: Client agreement. This information element provides a 
client’s opinion on whether an issue has been satisfactorily resolved. There is no 
formal production rule that relates it to it. The client provides her opinion, which is 
not governed by an algorithm. 


Solution 8.10 The solution is shown in Fig. 8.9. Note that the design is complete 
since all information elements of the product data model are covered. Note that not 
all production rules are included, i.e. there is no way to establish a value for A on 
the basis of a value for B. This, however, does not affect its completeness. Also note 
that the design is correct (check for yourself). 


Solution 8.11 The solution is shown in Fig. 8.10. Note that in this design as little 
work is done at each step, in search of opportunities to quickly terminate the process. 
First, the use of a value for D is pursued but, of course, an earlier result may not 
be available. Next, a value for F is created. Under certain circumstances, i.e. when 
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Fig. 8.10 A cost-efficient process design for the helicopter pilot product data model 


eye-sight is very bad, this may lead to a determination of a value for A (not suitable). 
If this fails to stop the process, there is no other option than to produce values for 
all remaining information elements. Compare this design with the solution for the 
previous exercise. 


8.7 Further Exercises 


Exercise 8.13 Following is the literal description of a redesign case at IBM Credit 
Corporation, taken from the book “Reengineering the corporation” by Hammer and 
Champy [29]. It is split up into several parts. Please read these and answer the ques- 
tions. 


Our first case concerns IBM Credit Corporation, a wholly owned subsidiary of IBM, which, 
if it were independent, would rank among the Fortune 100 service companies. IBM Credit 
is in the business of financing the computers, software, and services that the IBM Corpo- 
ration sells. It is a business of which IBM is fond, since financing customers’ purchases 
is an extremely profitable business. In its early years, IBM Credit’s operation was posi- 
tively Dickensian. When IBM field salespersons called in with a request for financing, they 
reached one of 14 people sitting around a conference room table in Old Greenwich, Con- 
necticut. The person taking the call logged the request for a deal on a piece of paper. That 
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was step one. In step two, someone carted that piece of paper upstairs to the credit depart- 
ment, where a specialist entered the information into a computer system and checked the 
potential borrower’s creditworthiness. The specialist wrote the results of the credit check 
on the piece of paper and dispatched it to the next link in the chain, which was the busi- 
ness practices department. The business practices department, step three, was in charge of 
modifying the standard loan covenant in response to customer request. Business practices 
had its own computer system. When done, a person in that department would attach the 
special terms to the request form. Next, the request went to a pricer, step four, who keyed 
the data into a personal computer spreadsheet to determine the appropriate interest rate to 
charge the customer. The pricer wrote the rate on a piece of paper, which, with the other 
papers, was delivered to a clerical group, step five. There, an administrator turned all this 
information into a quote letter that could be delivered to the field sales representative by 
Federal Express. 


(a) Model the described business process. Use pools and lanes where needed. 


The entire process consumed six days on average, although it sometimes took as long as two 
weeks. From the sales reps’ point of view, this turnaround was too long, since it gave the 
customer six days to find another source of financing, to be seduced by another computer 
vendor, or simply to call the whole deal off. So the rep would call time and again to ask, 
“Where is my deal, and when are you going to get it out?” Naturally, no one had a clue, 
since the request was lost somewhere in the chain. 


(b) Which dimension of the Devil’s Quadrangle would be dominant for a re- 
design? Give an exact definition of the performance criterion. 


In their efforts to improve this process, IBM Credit tried several fixes. They decided, for 
instance, to install a control desk, so they could answer the rep’s questions about the status 
of the deal. That is, instead of each department forwarding the credit request to the next 
step in the chain, it would return it to the control desk where the calls were originally taken. 
There, an administrator logged the completion of each step before sending the paper out 
again. This fix did indeed solve one problem: The control desk knew the location of each 
request in the labyrinth and could give the rep the information they wanted. Unfortunately, 
this information was purchased at the cost of adding more time to the turnaround. 


(c) Model the adapted process. Use pools/lanes where needed. (d) Can you ex- 
plain in terms of the performance dimensions of the Devil’s Quadrangle what has 
happened? 


Eventually, two senior managers at IBM Credit had a brainstorm. They took a financing 
request and walked it themselves through all five steps, asking personnel in each office to 
put aside whatever they were doing and to process this request as they normally would, 
only without the delay of having it sit in a pile on someone’s desk. They learned from their 
experiments that performing the actual work took in total only 90 minutes—one and a half 
hours. The remainder—now more than seven days on average—was consumed by handing 
the form off from one department to the next. Management had begun to look at the heart 
of the issue, which was the overall credit issuance process. Indeed, if by the wave of some 
magic wand the company were able to double the personal productivity of each individual 
in the organization, total turnaround time would have been reduced by only 45 minutes. The 
problem did not lie in the activities and the people performing them, but in the structure of 
the process itself. In other words, it was the process that had to change, not the individual 
steps. 

In the end, IBM Credit replaced its specialists—the credit checkers, pricers, and so on-with 
generalists. Now, instead of sending an application from office to office, one person called 
a deal structurer processes the entire application from beginning to end: No handoffs. 
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How could one generalist replace four specialists? The old process design was, in fact, 
founded on a deeply held (but deeply hidden) assumption: that every bid request was unique 
and difficult to process, thereby requiring the intervention of four highly trained specialists. 
In fact, this assumption was false; most requests were simple and straightforward. The old 
process had been over-designed to handle the most difficult applications that management 
could imagine. When IBM Credit’s senior managers closely examined the work the spe- 
cialists did, they found that most of it was little more than clerical: finding a credit rating 
in a database, plugging numbers into a standard model, pulling boilerplate clauses from a 
file. These activities fall well within the capability of a single individual when this is sup- 
ported by an easy-to-use computer system that provides access to all the data and tools the 
specialists would use. 

IBM Credit also developed a new, sophisticated computer system to support the deal struc- 
turer. In most situations, the system provides the deal structurer with the guidance needed 
to proceed. In really tough situations, the deal structurer can get help from a small pool of 
real specialists-experts in credit checking, pricing, and so forth. Even here handoffs have 
disappeared because the deal structurer and the specialists he or she calls in work together 
as a team. 

The performance improvement achieved by the redesign is extraordinary. IBM Credit 
slashed its seven-day turnaround to four hours. It did so without an increase in head count- 
in fact, it has achieved a small head-count reduction. At the same time, the number of deals 
that it handles has increased a hundredfold. Not 100 percent, but 100 times. 


(e) Consider the list of heuristics dealt with in this paper. Which of these can you 
recognize in the new process redesign? 


Exercise 8.14 Indicate in what respect the application of the Outsourcing heuristic 
and the composition of larger activities—as a specific case of the Activity composi- 
tion heuristic—can lead to similar or different results. Use the performance dimen- 
sions of the Devil’s Quadrangle and provide specific interpretations. 


Exercise 8.15 Consider the equipment rental process described in Example 1.1 
(p. 2) and the corresponding issues documented in Example 6.4 (p. 199). 


a Apply the redesign heuristics in order to address the issues documented in Exam- 
ple 6.4. 

b Capture the resulting to-be model in BPMN. 

c Explain the impact of the changes you propose in terms of the performance di- 
mensions of the Devil’s Quadrangle. 


Exercise 8.16 Consider the university admission process described in Exercise 1.1 
(p. 4) and the corresponding issues documented in Exercise 6.4 (p. 201). 


a Apply the redesign heuristics in order to address the issues documented in Exer- 
cise 6.4. 

b Capture the resulting to-be model in BPMN. 

c Explain the impact of the changes you propose in terms of the performance di- 
mensions of the Devil’s Quadrangle. 


Exercise 8.17 Consider the pharmacy prescription fulfillment process described 
in Exercise 1.6 (p. 28) and the corresponding issues documented in Exercise 6.9 
(p. 209). 


8.8 Further Reading 295 


a Apply the redesign heuristics in order to address the issues documented in Exam- 
ple 6.9. 

b Capture the resulting to-be model in BPMN. 

c Explain the impact of the changes you propose in terms of the performance di- 
mensions of the Devil’s Quadrangle. 


Exercise 8.18 Consider the procure-to-pay process described in Exercise 1.7 (p. 29) 
and the corresponding issues documented in Exercise 6.10 (p. 210). 


a Apply the redesign heuristics in order to address the issues documented in Exam- 
ple 6.10. 

b Capture the resulting to-be model in BPMN. 

c Explain the impact of the changes you propose in terms of the performance di- 
mensions of the Devil’s Quadrangle. 


8.8 Further Reading 


Michael Hammer has written many, highly worthwhile books with his co-authors 
on process redesign, for example [27, 29]. Other management books that deal with 
the topic are, for example, [10, 46, 86]. In contrast to the topic of process modeling, 
process redesign has not received so much attention from the scientific community. 
When BPR is studied, the focus is mostly on case studies or the diffusion of the 
concept in practice itself is studied, for example in which domains it is applied or 
in which countries it is most popular. One of the most interesting studies in this 
category is quite dated [62], but it clearly shows the problems of what was initially 
considered business process redesign and how it quickly evolved into a more in- 
cremental approach. A very interesting study into the characteristics of different 
redesign methodologies is provided in [41], which has inspired various concepts 
that were dealt with in this part of the book. 

The redesign heuristics that were discussed in this chapter have been described 
in quite some detail. After their initial presentation as best practices in [72], they 
have been validated and further analyzed in follow-up studies [47, 48]. Current ef- 
forts by various researchers are aimed at supporting practitioners in making sensible 
selections of redesign heuristics in specific cases [30, 44]. Also, attempts have been 
made to extend the set of redesign heuristics to their application in other domains, 
for example in [58]. 

Product-based Design was developed at Eindhoven University of Technology in 
cooperation with a Dutch consultancy company. Various case studies are available, 
which give a better idea of the practical application of this method and its poten- 
tial benefits [70, 71]. Recently, the emphasis of researchers working on this topic 
is moving towards the automatic generation of process designs and the automated 
support of the execution of such processes [100]. Another way of looking at Product- 
based Design is that it is an approach that blends data and process. This is currently 
a hot topic: In this sense, IBM’s artifact-centeric process modeling approach [36] 


296 8 Process Redesign 


and the data-driven process structures developed by the University of Ulm [57] are 
comparable approaches. 

One of the main open questions in the area of process redesign is to what extent 
it makes sense to follow industrial reference models or to try and develop company- 
specific designs. While industrial reference models are offered by many vendors, it 
is not so obvious that they represent the best possible way to carry out processes. 


Chapter 9 
Process Automation 


Besides black art, there is only automation and mechanization. 
Federico Garcia Lorca (1898-1936) 


This chapter deals with process automation. First, we will briefly explain what an 
automated business process is, after which we will focus on a specific kind of tech- 
nology that is particularly suitable to achieve process automation, i.e. Business Pro- 
cess Management Systems (BPMSs). We will explain the features and advantages 
of these systems, present the different types of BPMS, and discuss some of the chal- 
lenges that are involved with introducing a BPMS in an organization. Finally, we 
will discuss what changes are required to a business-oriented process model like 
the ones seen so far, to make it executable and run in a BPMS. 


9.1 Automating Business Processes 


Process automation is a subject that may be approached from different angles. In a 
broad sense, it may refer to the intent to automate any conceivable part of procedural 
work that is contained within a business process, from simple operations that are 
part of a single process activity up to the automated coordination of entire, complex 
processes. 

Take, for example, the order fulfillment process that we modeled in Chap. 3. Au- 
tomating such a process may imply that every time the seller receives a purchase 
order, this is automatically dispatched to the ERP systems of the warehouse and 
distribution department, where the availability of the product is checked against the 
warehouse database. If the product is not in stock, the relevant suppliers are auto- 
matically contacted, e.g. via a Web service interface, to manufacture the product. 
Otherwise, instructions are sent to a warehouse worker, e.g. using an electronic 
form, to manually retrieve the product from the warehouse. Subsequently, an or- 
der clerk from sales receives a notification that a new order needs to be confirmed, 
e.g. via email. That clerk would then log into the purchase order tracking system 
within sales, see the order electronically, and confirm it by pressing a button, and so 
on. 
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In this example the dispatching of the purchase order, the automated check of 
the product’s availability, or the automated web messages are all manifestations 
of process automation in its broadest sense: they automate a particular aspect of a 
process. In this context, we will refer to an automated business process, also known 
as workflow, as a process that is automated in whole or in part by a software system, 
which passes information from one participant to another for action, according to 
the temporal and logical dependencies set in the underlying process model. Let us 
now consider systems that work with automated business processes. 


9.1.1 Business Process Management Systems 


A specific kind of process automation, which we are particularly concerned with in 
this book, exploits knowledge about how different process activities relate to one an- 
other. In other words, the type of information systems that we consider are process- 
aware. The main category of process-aware information systems that we will dis- 
cuss are the so-called Business Process Management Systems (BPMSs). While there 
are other types of process-aware system, such as Customer Relationship Manage- 
ment (CRM) systems and Enterprise Resource Planning (ERP) systems, the special 
feature of BPMSs is that they exploit an explicit description of a business process, 
in the form of a process model, to coordinate that process. In that sense, a BPMS 
can be tailored to specific processes of any kind. 

The purpose of a BPMS is to coordinate an automated business process in such 
a way that all work is done at the right time by the right resource. To explain how a 
BPMS accomplishes that, it is useful to see that a BPMS is in some way similar to a 
Database Management System (DBMS). A DBMS is a standard, off-the-shelf soft- 
ware package offered by many vendors in many different flavors, such as Microsoft 
SQL Server, IBM DB2 or Oracle Database. With a DBMS it is possible to capture 
company-specific data in a structured way, without ever having to consider how the 
exact retrieval and storage of the involved data takes place. These tasks are taken 
care of by standard facilities of the system. Of course, at some point it is necessary 
to configure the DBMS, fill it with data, and it may also be necessary to periodically 
adapt the system and its content to actual demands. 

In a similar manner, a BPMS is also a standard type of software system. Ven- 
dors offer different BPMSs with a varying set of features, spanning the whole pro- 
cess lifecycle: from simple systems only catering for the design and automation of 
business processes, to more complex systems also involving process intelligence 
functionality (e.g. advanced monitoring and process mining), complex event pro- 
cessing, SOA functionality, and integration with third-party applications and social 
networks. Despite the variety of functionality a BPMS can offer, the core feature 
of such a software system resides in the automation of business processes. With a 
BPMS it becomes feasible to support the execution of a specific business process 
using the standard facilities offered by the system. However, it is essential that a 
business process is captured in such a way that the BPMS can deal with it, i.e. that 
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the BPMS can support its execution. From the moment a process is captured in a 
format that the BPMS can work with, it is important to keep that description of the 
business process up-to-date so that the process is supported properly over time. 

In the past, mainly before the emergence of BPMSs, there existed a large number 
of tools focused on process automation, which did not encompass process intelli- 
gence functionality and which had relatively minimal support for process model- 
ing. These tools were known under the name of Workflow Management Systems 
(WfMSs). Over time, many of these tools evolved towards BPMSs. Additionally, a 
plethora of stand-alone tools exist that cover a single feature of advanced BPMSs, 
such as stand-alone process modeling tools, process simulation tools and process 
analytics tools. All these tools provide value in supporting various parts of the BPM 
lifecycle, but do not generally support process automation. For this reason, they will 
not be the focus of this chapter. 


9.1.2 Architecture of a BPMS 


Figure 9.1 shows the main components of a BPMS, namely the execution engine, the 
process modeling tool, the worklist handler, and the administration and monitoring 
tools. The execution engine may interact with external services. 


Execution Engine Central to the BPMS is the execution engine. The engine pro- 
vides different functionalities including: (i) the ability to create executable pro- 
cess instances (also called cases); (ii) the ability to distribute work to process 
participants in order to execute a business process from start to end; (iii) the 
ability to automatically retrieve and store data required for the execution of the 
process and to delegate (automated) activities to software applications across the 
organization. Altogether, the engine is continuously monitoring the progress of 
different cases and coordinating which activities to work on next by generating 
work items, i.e. instances of process activities that need to be taken care of for 
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Fig. 9.2 The process modeling tool of Bonita Open Solution from Bonita Soft 


specific cases. Work items are then allocated to resources which are both qual- 
ified and authorized to carry out these. More specifically, the execution engine 
interacts with the other components, as discussed next. 

Process modeling tool The process modeling tool component offers functionality 
such as (i) the ability for users to create and modify process models; (ii) the abil- 
ity to annotate process models with additional data, such as data input and output, 
participants, business rules associated with activities, or performance measures 
associated with a process or an activity; and (iii) the ability to store, share and re- 
trieve process models from a process model repository. A process model can be 
deployed to the engine in order to be executed. This can either be done directly 
from the modeling tool or from the repository. The engine uses the process model 
to determine the temporal and logical order in which the activities of a process 
have to be executed. On that basis, it determines which work items should be gen- 
erated and to whom they should be allocated or which external services should 
be called. Figure 9.2 shows the process modeling tool of Bonita Open Solution 
from Bonita Soft. 

Worklist handler A worklist handler is the component of a BPMS through which 
process participants are (1) offered work items and (11) commit to these. It is the 
execution engine that keeps track of which work items are due and makes them 
available through the worklist handlers of individual process participants. The 
standard worklist handler of a BPMS can best be imagined as an inbox, simi- 
lar to that of an email client. Through an inbox, participants can see what work 
items are ready for them to be executed. The worklist handler might use elec- 
tronic forms for an activity’s input and output data. When a work item of this 
activity is selected and started by the participant from their worklist, the corre- 
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Fig. 9.3. The worklist handler of Bizagi’s BPM Suite 


sponding electronic form is rendered on screen. This step is called check-out. 
Participants can then enter data into the form, and signal completion to the en- 
gine. This step is called check-in. Afterwards, the engine determines the next 
work items that must be performed for the case in question. Often, participants 
can to some extent exert control over the work items in their worklist, e.g. with 
respect to the order in which they are displayed and the priority they assign to 
these work items. Also, a worklist handler will typically support a process par- 
ticipant in temporarily suspending work items or passing on control to someone 
else. Which exact features are available depends on the BPMS in question and 
its specific configuration. It is fairly common to customize worklist handlers, for 
example according to corporate design, to foster its efficient usage and accep- 
tance within an organization. Figure 9.3 shows the worklist handler of Bizagi’s 
BPM Suite. 


External services It may be useful to involve external applications in the execution 


of a business process. In many business processes, there are activities which are 
not to be executed in a completely manual fashion. Some of these activities can 
be performed fully automatically, such that the execution engine can simply call 
an external application, for example to assess the creditworthiness of a client. 
The external application has to expose a service interface with which the engine 
can interact. Thus, we simply refer to such applications as external services. The 
execution engine provides the invoked service with the necessary data it will need 
for performing the activity for a specific case. On completion of the request, the 
service will return the outcome to the engine and signal that the work item is 
completed. This, again, is stored in the execution log. Some other activities in a 
business process are neither completely manual nor completely automated. In- 
stead, such activities are to be performed by process participants with some form 
of automated support. For this category of activities, the execution engine will 
invoke the appropriate services with the right parameters, exactly at the moment 
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Fig. 9.4 The monitoring tool of Perceptive Software’s BPMOne 


that the employee selects a particular work item to work on. A typical example 
would be the invocation of a Document Management System (DMS) to display 
to the process participant a file that is important to carry out a specific work item. 
Think of the equipment rental request, where this would help a clerk to determine 
the appropriate piece of equipment to order. Sometimes too, a BPMS may need 
to transfer control over cases between different organizational units or organiza- 
tions. One way of achieving this is by interacting with an external BPMS which 
exposes a Service interface for this purpose. For example, consider a global in- 
surance company that has offices in three different time zones: Japan, the UK 
and California. At the end of the working day in each of these time zones, all 
work items can be transferred to the execution engine in the next zone where the 
work day has just started. In this way, the execution of the business process never 
stops. 

Administration and monitoring tools Administration and monitoring tools are 
the tools necessary for the administration of all operational matters of a BPMS. 
Consider, as a prime example, the actual availability of specific participants. If 
someone is unavailable to work because of illness or a vacation, the BPMS has to 
be made aware of this fact in order to avoid allocating work items to such a per- 
son. Administration tools are also required to deal with exceptional situations, for 
example to remove outdated work items from the system. Administration tools 
are also equipped with process monitoring functionality. One can use these tools 
to monitor the performance of the running business processes, in particular with 
respect to the progress of individual cases. These tools can aggregate data from 
different cases, such as average cycle times of cases, or the fraction of cases that 
are delivered too late. The BPMS records the execution of a process model step 
by step. The execution-related events recorded in this way are stored and can be 
exported in the form of execution logs. Some monitoring tools can analyze his- 
torical data extracted from the logs and compare it with live data (cf. Chap. 10). 
Figure 9.4 shows the monitoring tool of Perceptive Software’s BPMOne. 


This generic architecture, which underpins the functioning of any BPMS, is the 
evolution of a reference model for WfMSs which was proposed by the Workflow 
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Management Coalition (WfMC) in the nineties. A dedicated box “WfMC Reference 
Model” expands on this model. 

To illustrate how a BPMS works, recall BuildIT’s business process for renting 
equipment from Chap. |. Let us suppose it is supported by a BPMS. The execution 
engine can track that for orders # 1,220 and #1,230 site engineers have already filled 
out the equipment rental requests. On the basis of a process model of the renting 
equipment process, the execution engine can detect that for both of these cases the 
proper piece of equipment must be determined. This needs to be done by any of 
the clerks at the depot. Therefore, the BPMS passes on the request to all worklist 
handlers of all clerks for further processing. For order #1,240 on the other hand, the 
equipment rental request is not available yet. So, the BPMS engine will not pass on 
a similar request for this order yet. Instead, it will await the completion of this work 
item. 


Exercise 9.1 In which state is the process after all the actions of the rental process 
of BuildIT have been performed as described above? Which work items can you 
identify that are under control of the BPMS? Make sure to identify both the case 
and the activity for each work item. 


WfMC REFERENCE MODEL 

The Workflow Management Coalition (WfMC) is a standardization organiza- 
tion, founded in 1993, in which BPMS vendors, users and researchers have a 
seat. The purpose of the WfMC is to achieve generally accepted standards for 
terminology and interfaces for the components of a BPMS [35]. 

The WfMC has produced the so-called WfMC reference model which has 
become well-established in the world of process automation. The idea behind 
this reference model is that any supplier of a BPMS can explain the func- 
tioning of its specific system on the basis of it. The original reference model 
included six components, which resemble the components of the BPMS ar- 
chitecture in Fig. 9.1. They are: workflow engine, process modeling tools, ad- 
ministration and monitoring tools, worklist handler, external applications and 
external BPMSs. In the reference model, the interactions between its com- 
ponents take place through so-called interfaces, which are numbered from 1 
to 5. Three of these interfaces are still recognizable in the BPMS architecture 
that is discussed in this chapter: 


e Interface I concerns the interaction between the engine and process mod- 
eling tools, 

Interface 2 concerns the interaction between the engine and the worklist 
handler, 

Interface 5 concerns the interaction between the engine and the administra- 
tion and monitoring tools. 
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The other interfaces of the WfMC reference model are subsumed by re- 
cent developments. Interface 3 governed the interaction between IT applica- 
tions and the execution engine, but this has become outdated by the advent of 
standard service interfaces over the Web (e.g. Web services). Similarly, inter- 
face 4—which addressed the integration with external BPMSs—has also been 
subsumed since this can also be realized through standard service interfaces. 

While most components of the WfMC reference model reappear in the 
BPMS architecture of Fig. 9.1, it should be noted that the WfMC architecture 
does not include the process model repository and does not explicitly repre- 
sent execution logs. These elements, however, have become crucial assets in 
the area of process automation, analysis and redesign. 


Exercise 9.2 Consider the following questions about a BPMS: 


e Why would it not be sufficient to only create a business process model with the 
modeling tools, without any information on the types of resource that are avail- 
able? 

e In what situation will the execution engine generate multiple work items on the 
basis of the completion of a single work item? 

e Can you provide examples of external services that may be useful to be invoked 
when a participant wishes to carry out a work item? 

e What would be a minimal requirement to be able to pass on work items between 
the BPMSs of the insurance company that was provided as an example? 

e If it is important that a BPMS hands out work items to available resources, can 
you imagine other, relevant types of information on resources that are useful to 
be captured by an administration tool (apart from whether they are ill or on vaca- 
tion)? 


9.1.3 The Case of ACNS 


Building on the explanation of the BPMS architecture in the previous section it 
is now possible to sketch an example of an operational BPMS. We use a simplified 
view on a process in which claims are assessed within the ACNS company (A Claim 
is No Shame). The first activity in this process is an assessment of the claim, which 
is to be done by a senior acceptor or a regular acceptor. A regular acceptor is only 
qualified to make this assessment in the situation where the claim amount of a case 
is below €1,000. In case of a negative assessment, it is the responsibility of the 
account manager to convey the bad news to the customer. In case of a positive as- 
sessment, an electronic invoice is to be generated by a clerk of the finance depart- 
ment, who needs to dispatch that to the client in question. After these activities, the 
process is completed. 
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The above description shows that there are two dimensions that must be cov- 
ered with the process modeling tool of the BPMS: (1) the procedure that specifies 
the various activities and (2) the various participants who are involved in carrying 
out these activities. The former part is recorded in a process model; the second is 
captured in, what is often referred to as, a resource classification. In addition, the re- 
lations between these models or specifications must be defined, i.e. who is able and 
qualified to perform which activity. Often, these relations are also specified as part 
of the process model. These relationships may not be static but be dependent on all 
kinds of business rule. For example, the distinction between the authorization levels 
of the senior and ordinary acceptor in assessing claims is an example of a dynamic 
tule, i.e. it is determined by the current value one of a piece of information. 

Once these descriptions are defined, the execution engine of a BPMS would gen- 
erally be able to support this process. Now let us assume that almost simultaneously 
two claims come in: 


1. Acar damage of €12,500, as claimed by Mr. Bouman. 
2. Acar damage of €500, as claimed by Mrs. Fillers. 


Ms. Withagen has been with ACNS for a long time and, for the past years, func- 
tions on the level of a senior acceptor. This month, Mr. Trienekens has started his 
training and works as an acceptor. At the start of his contract, the system admin- 
istrator, Mr. Verbeek, has used the administration tool of the BPMS to add Mr. 
Trienekens to the pool of available acceptors. 

Based on the process model, the resource classification, and operational data on 
the availability of the various employees, the enactment service of the BPMS now 
takes care of forwarding both newly received claims to the worklist handlers of 
Ms. Withagen. After all, she may assess both claims based on her qualifications. 
Mr. Trienekens, in his turn, will only see in his worklist handler the damage claim 
of Mrs. Fillers. 

On noting the work item in his worklist, Mr. Trienekens starts to work on it im- 
mediately. He selects the damage claim of Ms. Fillers to deal with. In response to 
that action, the execution engine ensures that the corresponding work item disap- 
pears from the worklist of Ms. Withagen. The reason, of course, is that this piece of 
work needs to be carried out only once. In any case, Ms. Withagen is still working 
on the handling of an earlier case, but shortly thereafter selects the claim of Mr. 
Bouman to deal with through her worklist handler. 

In response to the selection of work items by both Mr. Trienekens and Mrs. With- 
agen, the execution engine will ensure that both will see the electronic claim file on 
their screen of the respective customers. The execution engine does so by using the 
appropriate parameters in invoking the DMS of ACNS at the workstations of the 
acceptors. The DMS also displays the scanned version of the claims, which were 
originally sent in on paper. In addition, the BPMS takes care of displaying to both 
the acceptors an electronic form that they can use to record their assessment, also 
through the invocation of a service. 

Mr. Trienekens decides to reject the claim. The worklist handler notices this, 
because it monitors the specific field on the electronic form that receives a negative 
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value. Based on the logic captured in the process model, the execution engine can 
determine that the case must be handed over to the account manager of Ms. Fillers 
and sends a work item to that participant, requesting to inform the client on the 
negative assessment. 

Ms. Withagen arrives at a positive assessment of the claim under her watch and 
decides to approve it. The execution engine ensures that a service is invoked to deter- 
mine the new monthly premium for Mr. Bouman, taking into account his no-claim 
history which is registered in a claim database. The retrieval of the information from 
this database is also realized through a service. Once this calculation is completed, 
a work item for the various available financial employees is created to pay the dam- 
age. The work item appears in the worklist of each of these financial officers, until 
one of them selects it for processing. After the payment has been carried out, the 
process is completed. 

As can be seen in the ANCS example, all components of the BPMS architecture 
play a role in coordinating the work, specifically to ensure that the appropriate work 
items are created and carried out by the involved participants. 


Exercise 9.3 Consider the following developments and indicate which components 
of the BPMS architecture are affected when they are to be taken into account: 


1. A new decision support system is developed to support acceptors in making their 
assessment of claims. 

2. Ms. Withagen retires. 

3. A new distinction between claims becomes relevant: regular acceptors are now 
also qualified to deal with claims above €1,000 as long as they worked on pre- 
vious claims by the same client. 

4. Claims that are issued on cars which are over 10 years old need to be continu- 
ously monitored by management. 


Up to this point, we have discussed BPMSs as if they are particular software 
packages that deliver more or less the same functionality. However, it is closer to the 
truth to state that there are distinct flavors of BPMSs and that different organizations 
or different processes within the same organization may be best served by different 
types of BPMS. This observation is further discussed in the box “Types of BPMS”. 


TYPES OF BPMS 

There are several ways to distinguish between the available BPMSs. One clas- 
sification is based on the use of two axes: one that captures the degree of sup- 
port that the BPMS delivers and the other that expresses how that systems 
differ from each other with respect to their orientation on process or data. We 
describe and illustrate four different types of system: groupware systems, ad- 
hoc workflow systems, production workflow systems, and case handling sys- 
tems. These systems can be positioned in the spectrum of BPMSs as shown 
in Fig. 9.5. 
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Fig. 9.5 The spectrum of BPMS types 


Groupware systems: The two underlying principles of groupware systems 
are that the user is enabled to easily share documents and information on 
the one hand and to directly communicate with other users on the other. 
The best known example of a groupware system is IBM’s Lotus Notes. 
Groupware systems are very widely used and particularly popular for their 
high operational flexibility. When it comes to supporting business pro- 
cesses, these systems cannot do such in a strict sense. Groupware systems 
traditionally do not support an explicit notion of the business processes; 
however, extensions like Lotus Domino Workflow exist as well. 

Ad-hoc workflow systems: Ad-hoc BPMSs, like TIBCO’s BusinessWorks 
or Comalatech’s Ad-hoc Workflows, allow on-the-fly process definitions 
that can be created and modified. So, even though there is already a pro- 
cess definition in existence to deal with a case type, it is possible during the 
execution of that process to adapt the process, for example to include an 
additional step. For these kinds of system, it is often so that each case (an 
order, claim, complaint, etc.) has its own private process definition. This 
prevents many problems that are acclimated with updating a general pro- 
cess definition when it has running instances. Clearly, ad-hoc BPMSs al- 
low much flexibility. The BPMS InConcert, for example, even allows users 
to trigger a business process instance on the basis of a completely empty 
process definition, which is extended as it becomes clearer what needs to 
happen and in what order. Another direction is that initially the BPMS 
works on the basis of a standard solution or template, which can be mod- 
ified at will. Interestingly, such a modified procedure may be used as the 
template for starting the processing of a new case. In general, there are two 
major requirements to successfully apply ad-hoc BPMSs in an organiza- 
tion. The first requirement is that end users are very aware of the processes 
in which they operate. This means that only processes should be defined 
or modified by people with a very good overview of the process and the 
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consequences of deviating from usual practice. The second requirement is 
that users have sophisticated tools at their disposal to model business pro- 
cesses and that they are capable of modeling. The combination of these 
requirements hinders the wide-scale application of ad-hoc BPMSs at this 
point. 

Production workflow systems: The most familiar type of BPMS is the pro- 
duction workflow system. Typical representatives are IBM’s Business Pro- 
cess Manager and Bizagi’s BPM Suite. Much of what we described in 
the previous sections on workflow applies to this class of BPMSs. Work 
is routed strictly on the basis of explicitly defined process descriptions 
captured in process models. Managing data, such as documents or e-mail 
support, is generally not offered by these systems. In general, it is also 
impossible or hard to deviate from a process logic if that has not been ex- 
plicitly captured in the process model. Sometimes a further distinction is 
made within production workflow into administrative and transaction pro- 
cessing BPMSs. This makes it possible to distinguish further shades with 
respect to the degree of automation of the work that is coordinated. Ad- 
ministrative BPMSs, are used in settings where a (large) portion of work is 
still performed by people; transaction processing BPMSs support business 
processes that are (almost) fully automated. 

Case handling systems: The idea behind a case handling system (or Adap- 
tive Case Management system) is that it does not strive for a tight and 
complete specification of a business process in a model. Rather, implicit 
process models are used, which capture a conventional flow from which— 
unless this is explicitly prohibited—a user can deviate. A case handling 
system is usually fully aware of the precise details of the data belonging 
to a case (including customer data, financial or medical data). On the ba- 
sis of such awareness, the system is able to provide end users a highly 
precise insight into the status of a case, as well as the most obvious steps 
to continue the process. Contemporary examples are i-Sight’s Case Man- 
agement Software and BPMOne by Perceptive Software. The latter also, 
if desired, supports a production workflow approach and in that sense is a 
hybrid BPMS. 


There are other types of system that share characteristics and functionality 
with BPMSs. Document management systems (DMSs) primarily take care of 
the storage and retrieval of documents, like document scans and PDFs, but 
they often offer workflow automation features as well. An example is Adobe’s 
LiveCycle Enterprise Suite. Process Orchestration Servers focus on process 
automation but have a specific emphasis on automated processes that require 
the integration of multiple enterprise applications. An example is Oracle’s 
SOA Suite. 
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9.2 Advantages of Introducing a BPMS 


In this section we reflect on why it would be attractive for organizations to use a 
BPMS. There are four broad categories of advantages which we will discuss here: 
workload reduction, flexible system integration, execution transparency, and rule 
enforcement. 


9.2.1 Workload Reduction 


A BPMS automates part of the work that is done by people in settings where such 
a system is not in place. First of all, it will take care of transporting work itself. In 
a paper-based organization, work is usually transported by internal postal services, 
often delaying processing for one work day at each handover, or by the participants 
themselves at the expense of their working time. All such delays are completely 
eradicated when a BPMS can be used to dispatch work items electronically. In some 
situations, the BPMS can take care of the entire process by invoking fully automated 
applications. In such cases, we speak of Straight-Through-Processing (STP). Partic- 
ularly in the financial services, many business processes that used to involve human 
operations are now in STP mode and coordinated by BPMSs. Also in other domains, 
think for instance of electronic visa, at least a portion of the cases can be handled in 
a completely automatic fashion. 

The second type of work that is being taken over by the BPMS concerns coor- 
dination. The BPMS uses the process model for determining which activities need 
to be performed and in what order. So, every time the BPMS uses this knowledge 
to route a work item it potentially saves someone the time to even think about what 
should be done next. Another form of coordination time saved is the signaling of 
completed work. In a paper-based organization, work will be lying around for quite 
some time in case of work hand-overs. What often happens is that someone takes 
over work, suspends it for some reason, after which the work package gets stuck in 
another pile of work. The BPMS will at all times be able to signal the status of all 
work items and it can take actions to ensure that progress is being made. 

The final type of workload reduction by using a BPMS is the gathering of all rel- 
evant information to carry out a particular task. In a situation without a BPMS, it is 
the employee who needs to do this collection. Finding the right file in particular—it 
is never there where you would expect it—can be a time-consuming affair. Note that 
this type of advantage rests on the assumption that along with the introduction of the 
BPMS the effort is taken to digitalize the stream of documents in an organization. 
The implementation of a DMS is actually what is often observed alongside a BPMS 
implementation. Certain vendors, such as IBM and Perceptive Software, offer in- 
tegrated suites of BPMS and DMS functionality. Other BPMS vendors often have 
strategic cooperations with companies that offer a DMS, such that it is relatively 
easy to integrate their joint systems. 
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9.2.2 Flexible System Integration 


Originally, the most mentioned argument to start with a BPMS is the increased 
flexibility that organizations achieve with this technology. To explain this best, a 
short reflection on the history of computer applications is due. There is an interesting 
trend, as identified by Van der Aalst and Van Hee [95] that generic functionality is 
split off from applications at some point. 

Roughly throughout the 1965-1975 period, computer applications were run di- 
rectly on the operating systems (OS) of a computer. Each application would take 
care of its own data management and would be using proprietary techniques to do 
this efficiently. As a result, it turned out to be difficult to share data among appli- 
cations and to maintain consistency. Clearly, programmers of different applications 
would be involved with developing similar routines to solve similar problems. From 
1975 onwards, DBMSs as a new type of standard software emerged that took on the 
generic task of managing data efficiently. As a result, data could be shared rather eas- 
ily and programmers of new applications would not need to worry anymore about 
ways to store, query, or retrieve date. Some 10 years later, around 1985, User In- 
terface Management Systems (UIMS) were introduced to provide a very generic 
interface component to many applications. Through the provision of facilities like 
drop-down boxes or radio buttons in accessible libraries, each computer program- 
mer would be able to make use of these. By 1995, the first commercial BPMSs enter 
the market place (considerable time before, research prototypes have been avail- 
able). Like DBMSs and UIMSs in their focus area, BPMSs would provide generic 
support for the area of business process logic. 

The introduction of a BPMS is a logical sequel to the separation of generic func- 
tionality of what were one monolithic computer programs. Still in the 1990s, it was 
estimated that 40 % of all the lines of code running on the mainframe computers 
of banks would have to do with business process logic, not with the calculations 
or data processing themselves. The typical kind of information processing in the 
context relates to the identification of activities, their order of execution, and or the 
participants responsible for carrying them out. For example, it would be specified 
that after a mortgage offering was completed, this needed to be signaled to the man- 
ager of the department, triggering a signal on her monitor. 

The obvious advantage related to this development is that it has become much 
easier with a BPMS to manage business process logic on its own. This is due to 
the fact that it is much more convenient to update the description of a business pro- 
cess without having to inspect the application code. Also, the reverse would become 
easier, i.e. modifying an application while not touching on the order of how things 
on the business process level would need to unfold. BPMSs, in short, would en- 
able organizations to become more flexible in managing and updating their business 
processes as well as their applications. 

BPMSs also provide the means to glue together separate systems. Large service 
organizations typically deploy myriads of IT systems, which all exist more or less 
independent of each other. Often, such a situation is referred to as island automa- 
tion. A BPMS may be introduced in such a situation as a means of integrating such 
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systems. It will safeguard that all the separate systems will play their due role in the 
business process they support. 

A word of caution is due here. The BPMS itself will offer no direct solution 
to the problem that there is often a redundant storage of information across many 
different IT systems. In fact, a BPMS will in general have no knowledge of the actual 
data that end users will manipulate using the various IT systems. If the BPMS is to 
operate as an integrator between all the existing systems, this will require a thorough 
information analysis to map which data is used and available. 


9.2.3, Execution Transparency 


An advantage that is often overlooked is that a BPMS can operate as a treasure trove 
with respect to the way that business processes are really executed. It is likely that 
the developers of the first BPMSs did not clearly have any advantage in mind on 
providing any insights about the execution of a process to anyone else than people 
executing the process itself. Sure enough, to have a BPMS operate at all, it must 
keep an accurate administration on which work items are due, which can only be 
determined by actively monitoring and recording which work items have been com- 
pleted by which resources and at what time new cases enter the process. Yet, for a 
BPMS to function properly, it is not necessary to keep all that data available once the 
associated cases are completed. The management overseeing such a process, how- 
ever, may have an entirely different perspective on this issue. There are two types 
of information that may be useful to generate interesting insights on basis of the 
administration a BPMS keeps: 


1. Operational information, which relates to recent, running cases, and 
2. Historic information, which relates to completed cases 


Operational information is relevant for the management of individual cases, par- 
ticipants, or specific parts of a business process. A characteristic example is the 
following. From analyses of various governmental agencies involved with granting 
permits in the Netherlands it has become clear that determining the exact status of 
a permit application was one of the most time-consuming activities for the civil 
servants involved. By the use of most commercially available BPMSs, retrieving 
that status is a futility. Such a status may be, for example, that the request of Mr. 
Benders to extend his house with an extra garden wing has been received, matched 
with the development plans for the area he is living in, and that further processing 
is now dependent on the receipt of the advice of an external expert. Another use of 
operational information would relate to the length of queue in terms of work items. 
For example, there are 29 applications for building permits that await the advice 
of an external expert. From these examples it may become clear that initiatives to 
improve customer service, in particular with respect to answering questions about 
their orders, often relies on the use of a BPMS. 

Historic information, in contrast to operation information, is often of interest on 
a particular level of aggregation, for example covering more cases over an extended 
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period of time. This kind of information is of the utmost importance to determine 
the performance of a particular process or its conformance to particular rules. With 
respect to the former, you may want to think of average cycle times, the number of 
completed cases over a particular period, or the utilization of resources. The latter 
category could cover issues like the kind of exceptions that have been generated or 
the number of cases that violated a particular deadline. 

It makes sense to consider the kind of insights that need to be retrieved from a 
BPMS before it is actually implemented in an organization. Technical issues play 
a role here, like the period of time that the logs of a BPMS need to be kept and, 
therefore, how much storage space should be devoted for that. Consider that it be- 
comes a bit problematic if historic information is important on the aggregate level 
of years if there is only space to save the events of at most a months. There are also 
conceptual issues. If it is important to monitor a certain milestone within a process 
it is essential that it makes part of the process model that is used for the execution 
of the related business process. To use the previous example: If it is important to be 
able to recognize the stage in which a case has to wait for the advice of an external 
expert, then that milestone must be part of the process model. In this way, process 
automation provides the foundation for process intelligence (cf. Chap. 10). 


9.2.4 Rule Enforcement 


Except for the obvious advantage that a business process could be executed more 
efficiently by using a BPMS, such a system will also take care of that the process is 
carried out in precisely the way that it has been designed. When rules are explicitly 
enforced, this can be considered as a quality benefit: one does, what one promises. 
In many settings, employees will have considerable freedom to carry out a business 
process in the way it looks best to them (or most convenient). This individual assess- 
ment does not necessarily coincide with the best possible way a business process is 
executed from the overall perspective of an organization. In this respect, a BPMS 
can be a means to safeguard that business processes are executed in a predefined 
way, without any concessions. 

As an illustration, consider the separation of duties control that is well known 
in the financial services domain. It means that the registration and inspection of a 
financial transaction will need to be carried out by different individuals. This type of 
logic is both quite easily implemented in BPMSs and enforced by such systems. The 
BPMS registers which individuals have carried out which work items and can take 
this information into account when allocating new work items. Note that a BPMS is, 
in general, sufficiently sophisticated so that employees can alternatively fulfill the 
registering and inspecting role for different cases. 

The capacity of a BPMS to enforce rules is currently of much interest to orga- 
nizations. Until a decade ago, primarily governmental organizations were imple- 
menting such systems purely motivated by this concern. After all, there are various 
laws that such organizations have to conform with. Nowadays, financial and other 
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professional service organizations have become similarly enamored by BPMSs. An 
important development in this is the rise of various governance frameworks, which 
started in 2002 with the Sarbanes—Oxley Act as a reaction to misconduct in Enron 
and Worldcom. The law places a high responsibility with company executives to 
install management controls and procedures within organizations and to see their 
proper execution. Obviously, this is were BPMSs can play an important role. 


Exercise 9.4 To which categories would you classify the following incentives to 
introduce a BPMS in an organization? 


e An auditing agency has found that the written procedures and actual execution of 
business processes are not aligned. The management of that organization wishes 
to enforce the written procedures and decides to introduce a BPMS. 

e The clients of an organization complain that they can only get very shallow up- 
dates on the progress of the orders they make. The IT manager of that organiza- 
tion looks into the use of a BPMS to capture and provide status information of all 
these order. 

e An insurance organization finds out that there is a high need to quickly adjust the 
way claims processing is carried out to the offerings that its competitors bring to 
the market. Using a BPMS is considered to address this demand. 


9.3 Challenges of Introducing a BPMS 


Despite the many advantages of using BPMSs, there are some notable obstacles 
with respect to introducing these in an organization. We will distinguish between 
technical and organizational challenges here. 


9.3.1 Technical Challenges 


What should be one of the strengths of a BPMS is also one of the pitfalls. A BPMS 
is capable of integrating the use of different types of information system in their 
support of a business process. The challenge is that many applications have never 
been developed with this coordinated use in mind. The mainframe applications that 
can still be found within banks and insurance companies today are notorious in this 
regard. In the most favorable case, such systems are technically documented but it 
happens often that there is no one of the original development team available any- 
more who knows exactly how these are structured. In such cases, it is very hard to 
determine how a BPMS can trigger such systems to make them support the execu- 
tion of a particular work item, to exchange information between the BPMS and such 
a system (e.g. case data), and how to determine when an employee has used such a 
system to complete a particular work item. 
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A technique that has been used to make interaction with such legacy systems at 
all possible is screen scraping. The interaction between a BPMS and the mainframe 
application then takes place on the level of the user interface: the key strokes that 
an end user should make are emulated by the BPMS and the signals sent to the 
display are tracked to establish the progress of carrying out an activity. It will come 
as no surprise that such low-level integration solutions will incur much rigidity to 
the overall solution and will, in fact, undermine the flexibility advantages that are 
normally associated with using a BPMS. 

A specific problem that occurs with respect to the integration of existing appli- 
cations with BPMSs is the lack of process-awareness of traditional systems. In a 
process-aware system, separate cases will be handled separately. In other words, 
such a system works on a case-by-case basis. In many traditional systems, batch 
processing is the dominant paradigm. This means that a particular task is executed 
for a potentially large set of cases, which does not always go well with the philos- 
ophy of a BPMS. Note how the Case-based work heuristic mentioned in Chap. 8 
explicitly targets this situation. 

Fortunately, in the area of system integration much progress has been made in 
the past decade. Many old systems are being phased out and new, open systems 
with clearly defined interfaces take their places. Technologies that are referred to 
as Middleware and Enterprise Application Integration tools are now available that 
strongly facilitate the communication and management of data in distributed appli- 
cations. Microsoft’s BizTalk and IBM’s WebSphere are well-known software suites 
that can be used in this respect and there are open source technologies available as 
well. The success of Web services is another driver behind improved, coordinated 
use of different types of information system, including BPMSs. A Web service is a 
piece of functionality, for example the identification of the best possible price for a 
particular good within a range of providers of that good, which can be invoked over 
the Internet. Most BPMSs provide good support for integrating specific Web ser- 
vices in executable business processes. This kind of set-up would fit within a popu- 
lar software architecture paradigm that is commonly referred to as Service-Oriented 
Architecture. 

With respect to technical integration capabilities it is fair to say that recent devel- 
opments are favorable for the use of BPMSs and that technical challenges, at least 
with respect to this aspect, are likely to further decrease over the next years. 


9.3.2 Organizational Challenges 


The introduction of an operational BPMS often has an impact on extensive parts 
of an organization. This implies that the introduction of a BPMS can be challeng- 
ing from an organizational perspective. The interests of different stakeholders have 
to be balanced, who usually have diverging performance objectives and vie for the 
same resources. Getting an insight into how existing processes unfold is an enor- 
mous challenge in itself, sometimes taking months of work. Here, not only political 
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motives may play a role—not everyone will be happy to give away how work is 
done, especially if not much work is done at all—but psychological ones as well: 
people tend to focus on describing the worst possible exceptions when asked to de- 
scribe what their role is in a process. One scholar has referred to this tendency as 
the reason “why modelers wreck workflow innovation”. 

A factor that adds to this complexity is that organizations are dynamic entities. 
It is fairly usual that during the introduction of a BPMS, which may span a cou- 
ple of months, organizational rules change, departments are scrapped or combined, 
participants get other responsibilities, new products are introduced or taken off the 
market. These are all examples of events that may be important to consider when the 
aim is to make a BPMS function properly in an organizational setting. In practice, 
this accounts for the insight that the gradual introduction of a BPMS is usually more 
successful than a “big bang” strategy, in which a BPMS from one day on the other 
is expected to replace the way operations were managed. 

The perspective of the users on the introduction of a BPMS should be considered 
carefully. Most subject experts will first need to experience hands-on what it is to 
use a BPMS before they can really appreciate what that means for their job. There 
may also be concerns and fears. First, there might be a “Big brother is watching 
you” sentiment. Indeed, a BPMS will record all the events that are involved with 
executing a process, including who carried out what piece of work and at what time. 
It makes no use—and from a change management perspective, it could actually be 
self-defeating—to ignore this concern. Rather it is up to organizations to clarify how 
this information will be used and that there are positive effects that can be expected 
of the usage of this information as well. Another fear that is common with end users 
of BPMSs is that their work will take on a mechanistic trait, almost as if they are 
working on a chain gang. This fear is in part genuine. It is true that the BPMS will 
take care of the allocation and routing of work. What can be argued, though, is that 
these are not the most exciting or valuable parts of the work that needs to be done 
(which is precisely the reason that they could be automated in the first place). If 
you would consider the situation where an employee needs to spend large parts of 
their time on finding the right information to do the job properly, the BPMS can 
be a favorable mechanism to give that time back to the employee. Another line of 
reasoning is that it highly depends on the configuration of the BPMS whether the 
mechanization effect will actually occur. Compare, for example, the situation where 
a BPMS pushes a single work item at a time to an employee to be carried out or 
rather a range of work items that someone could choose according to one’s own 
preferences. These options, which result from a configuration decision, can make a 
huge difference in the perception of the value of the BPMS. 

To sum up, the introduction of a BPMS is particularly complex, precisely because 
it supports entire business processes. It is not for nothing that out of many research 
projects into IT projects “strong management commitment” is always on top of 
the factors that explain successful implementations. The introduction of a BPMS 
is, perhaps even more so than for other types of technology, not for the faint of 
heart. 
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Exercise 9.5 Consider the following issues that come up when introducing a BPMS 
in a hospital to support preoperative care, i.e. the preparation and management of a 
patient prior to surgery. Classify these to the technical or organizational issues, or 
both. 


1. On hearing about the plans to introduce a BPMS, the surgeons flatly reject to 
cooperate on this endeavor. Their claim is that each patient is an individual person 
that cannot be trusted to the care of a one-size-fits-all system. 

2. The anesthetists in the hospital use a decision support system that monitors the 
proper dosage of anesthetics to patients. The system is developed as a stand- 
alone system that is difficult to synchronized with the BPMS, which has to feed 
the decision support system with patient data. 

3. The nurses are provided with mobile devices, which they can use to access their 
worklist handlers. However, they find it difficult to follow up on the automatic 
notifications which are signaled to them as gentle vibrations of the device. 


9.4 Turning Process Models Executable 


In this section we will show how to automate a business-oriented process model in 
order to execute it on a BPMS. In particular, we will consider the case of production 
BPMSs. 

Mapping processes for automation requires an approach to process modeling that 
is quite different from what is needed for communication or analytically focused 
process models. In fact, because of their intent, business-oriented process models are 
not necessarily precise and may thus contain ambiguities. Conversely, executable 
process models must be precise specifications in order to be interpreted by a BPMS. 

We propose a five-step method to incrementally transform a business-oriented 
process model into an executable one, as follows: 


. Identify the automation boundaries 

. Review manual tasks 

. Complete the process model 

. Bring the process model to an adequate granularity level 
. Specify execution properties 


nk WN 


Through these steps, the business-oriented model will become less abstract and 
more IT-oriented. These steps should be carried out on a process model that is both 
correct in terms of structure and behavior. For example, if the model contains behav- 
ioral errors like a deadlock, the BPMS may get stuck while executing an instance 
of this process model, with a potential impact on the operations of the organization. 
We have already discussed process model verification in Sect. 5.4. From now on we 
assume that the process model is correct. 
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9.4.1 Identify the Automation Boundaries 


First, we need to identify what parts of our process can be coordinated by the BPMS, 
and what parts cannot. In a process there are automated, manual and user tasks. 
Automated tasks are performed by the BPMS itself or by an external service while 
manual tasks are performed by process participants without the aid of any software. 
A user task sits in-between an automated and a manual task. It is a task performed 
by a participant with the assistance of the worklist handler of the BPMS or of an 
external task list manager. 

This difference between automated, manual and user tasks is relevant: automated 
and user tasks can easily be coordinated by a BPMS, while manual tasks cannot. 
Thus, in this first step we need to identify the type of each task. Then, in the next 
step, we will review the manual tasks and assess whether we can find a way to hook 
up these tasks to the BPMS. If this is not possible, we will have to consider whether 
or not it is convenient to automate the rest of the process without these manual tasks. 

Let us consider again the order fulfillment process model that we created in 
Chap. 3, which is shown in Fig. 9.6 for convenience (for the moment, discard the 
activity markers). Let us assume we get this model from a business analyst and our 
task is to automate it from the seller viewpoint. This means we need to focus on the 
process in the Seller pool and discard the rest. The first activity, “Check stock avail- 
ability”, sits in the ERP lane. This means that already at the conceptual level it was 
identified as an automated task. ERP systems do provide modules to manage inven- 
tories which automatically check the stock levels of a product against a warehouse 
database. This activity is highly repetitive as it is performed for each purchase order 
received. Performing it manually would be very inefficient and expensive, since it 
would employ a process participant though it does not require any particular human 
skill. Similar considerations hold for “Check raw materials availability”, which is 
also an automated task. Another example is activity “Manufacture product”. This 
is performed by an equipment (the manufacturing plant) which exposes its func- 
tionality via a service interface. So from the perspective of a BPMS, this is also an 
automated activity. 

Continuing with our example, there are other tasks such as “Request raw mate- 
rials from Supplier 1(2)” and “Get shipping address” that are devoted to sending 
and receiving messages. These are also examples of automated tasks. They can be 
implemented via automatic e-mail exchange or Web service invocation (and BPMSs 
typically provide these capabilities), despite they are not explicitly modeled inside a 
system lane. Recall that we are looking at a business-oriented process model, where 
it may not be relevant to model via lanes all existing systems (in this case an e-mail 
service or a Web service). 

Other tasks like “Retrieve product from warehouse”, “Obtain raw materials from 
Supplier 1(2)” and “Ship product” are manual. For example, “Retrieve product from 
warehouse” requires a warehouse worker to physically pick up the product from the 
shelf for shipping. In the presence of a manual task we have two options: (i) we 
isolate the task and focus on the automation of the process before and after it, or 
(ii) we find a way for the BPMS to be notified when the manual task has started or 
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Fig. 9.6 The order fulfillment model that we want to automate 
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completed. We will get back to this point in the second step. For now, all we need 
to do is identifying these manual tasks. 

“Confirm order” is an example of a user task: it requires somebody in sales (e.g. 
an order clerk) to verify the purchase order and then confirm that the order is correct. 
User tasks are typically scheduled through the worklist handler of the BPMS. In our 
example, an electronic form of the purchase order will be rendered on screen for 
the order clerk, who will verify that the order is in good state, confirm the order and 
thus submit the form back to the execution engine. 

The distinction between automated, manual and user tasks is captured in BPMN 
via specific markers on the top-left corner of the task box. Manual tasks are marked 
with a hand while user tasks are marked with a user icon. Automated tasks are 
further classified into the following subtypes in BPMN: 


e script (script marker), if the task executes some code (the script) internally to 
the BPMS. This task can be used when the functionality is simple and does not 
require access to an external application, e.g. opening a file or selecting the best 
quote from a number of suppliers. 

e service (wheels marker), if the task is executed by an external application, which 
exposes its functionality via a service interface, e.g. “Check stock availability” in 
our example. 

e send (filled envelope marker), if the task sends a message to an external service, 
e.g. “Request raw materials from Supplier 1”. 

e receive (empty envelope marker), if the task waits for a message from an external 
service, e.g. “Get shipping address”. 


These markers apply to tasks only. They cannot be used on sub-processes since 
a sub-process may contain tasks of different types. The relevant markers for our 
example are shown in Fig. 9.6. 


Exercise 9.6 Assume you have to automate the loan assessment process model of 
Solution 3.7 for the loan provider. Start by classifying the tasks of this process into 
manual, automated and user ones and represent them with appropriate task markers. 


9.4.2 Review Manual Tasks 


Once we have identified the type of each task, we need to check whether we can 
link the manual tasks to the BPMS, so that we can maximize the value obtained by 
the BPMS. Alternatively, we need to isolate these tasks so that we can automate the 
rest of our process. There are two ways of linking a manual task to a BPMS: either 
we implement it via a user task or via an automated task. 

If the participant involved in the manual task can notify the BPMS of the task 
completion using the worklist handler of the BPMS, the manual task can be turned 
into a user task. For example, the warehouse worker performing task “Retrieve prod- 
uct from warehouse” could check-out a work item of this task from their worklist to 
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indicate that they are about to perform the job, manually retrieve the product from 
the shelf, and then check-in the work item back into the BPMS engine. Alterna- 
tively, check-out and check-in can be combined in a single step whereby the worker 
simply notifies the worklist handler that the job has been completed. 

In some cases, a participant may use the aid of technology integrated with the 
BPMS to notify the engine of a work item completion. For example, the ware- 
house worker could use a barcode scanner to scan the barcode of the raw materi- 
als being obtained. The scanner would be connected to the BPMS so scanning the 
barcode would automatically signal the completion of “Obtain raw materials from 
Supplier 1(2)”. In this case, the manual task can be implemented as a receive task 
awaiting the notification from the scanner, or by a user task handled by a worklist 
handler which in turn is connected to the scanner. If we use a receive task, the BPMS 
will only be aware of the work item’s completion, in which case informing the ware- 
house worker that a new work item is available would be outside the scope of the 
BPMS. If we use a user task, the worker will be notified of the new work item by the 
BPMS, and will use the scanner to signal the work item’s completion to the BPMS 
engine. Similar considerations hold for task “Ship order”. Since each manual task of 
our example can be linked with a BPMS, this process can be automated as a whole. 


Exercise 9.7 Consider the loan assessment model that you obtained in Exercise 9.6. 
Review the manual tasks of this model in order to link them to a BPMS. 


There are cases in which it is not convenient to link manual tasks to a BPMS. 


Example 9.1 Let us consider the university admission process described in Exer- 
cise 1.1, with the improvements discussed in Solution 1.5. The process until the 
point where the application is batched for the admissions committee (shown in 
Fig. 9.7a) can be automated. Once all the applications have been batched, the com- 
mittee will meet and examine all of them at once. However, this part of the process 
(shown in Fig. 9.7b) is outside the scope of a BPMS. The tasks required for assessing 
applications cannot be automated because they involve various human participants 
who interact on an ad-hoc basis, and it would not be convenient to synchronize all 
these tasks with the BPMS. Eventually, the committee will draw a list of accepted 
candidates, transfer it to the admissions office, and a clerk at the admissions office 
will update the various student records, at which time the rest of the process can 
proceed within the scope of the BPMS (shown in Fig. 9.7c). 

In this example we cannot automate the whole process. So we need to isolate ac- 
tivity “Assess application’, an ad-hoc activity containing various manual tasks, and 
automate the process before and after this activity. An option is to split the model 
into three fragments as shown in Fig. 9.7 and only automate the first and the third 
fragment. Another option is to keep one model, and simply remove the ad-hoc activ- 
ity. Some BPMSs are tolerant to the presence of manual tasks and ad-hoc activities 
in executable models, and will discard them at deployment time (like comments in a 
programming language). If this is the case, we can keep these elements in. Observe 
the use of the untyped event to start the third process model fragment in Fig. 9.7. In 
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Fig. 9.7 Admission process: the initial (a) and final (c) assessments can be automated in a BPMS; 


the assessment by the committee (b) is a manual process outside the scope of the BPMS 
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BPMN, a process that starts with an untyped event indicates that instances of this 
process are explicitly started by a BPMS user, in our case a clerk at the admissions 
office. This process initiation is called explicit instantiation as opposed to implicit 
instantiation where process instances are triggered automatically by the event type 
indicated in the start event, e.g. an incoming message or a timer. 


Finally, when the process is mostly or entirely made up of unordered manual 
tasks, automation does not provide any benefit, and is often even unfeasible. Take 
for example the post-production process in the screen industry. Activities like “Hold 
spotting session”, where director and composer watch the picture to decide the mu- 
sic cues, “Conduct negative cutting”, where the camera negative is manually cut and 
spliced to match the final edit specified by the film editor, and “Compose sound- 
track’, can hardly be coordinated by a BPMS, since there is no strict order for their 
execution and each of them may be repeated multiple times. As a rule of thumb, 
a process whose tasks are performed in an ad-hoc manner, without any predictable 
order, is not suitable for automation via a production BPMS. In this case, a case 
handling or ad-hoc workflow system would be more appropriate. 


Exercise 9.8 Consider the final part of the prescription fulfillment process de- 
scribed in Exercise 1.6: 


Once the prescription passes the insurance check, it is assigned to a technician who collects 
the drugs from the shelves and puts them in a bag with the prescription stapled to it. Af- 
ter the technician has filled a given prescription, the bag is passed to the pharmacist who 
double-checks that the prescription has been filled correctly. After this quality check, the 
pharmacist seals the bag and puts it in the pick-up area. When a customer arrives to pick 
up their prescription, a technician retrieves the prescription and asks the customer for their 
co-payment or for the full payment in case the drugs in the prescription are not covered by 
the customer’s insurance policy. 


One way of modeling this fragment is by defining the following tasks: “Check 
insurance”, “Collect drugs from shelves”, “Check quality’, “Collect payment” (trig- 
gered by the arrival of the customer), and finally “Retrieve prescription bag”. As- 
sume the pharmacy system automates the prescription fulfillment process. Identify 
the type of each task and if there are any manual tasks, specify how these can be 


linked to the pharmacy system. 


There are other modeling elements, besides manual tasks, that are relevant at a 
conceptual level but cannot be interpreted by a BPMS. These are physical data ob- 
jects and data stores, messages bearing physical objects and text annotations. Pools 
and lanes are also used at a conceptual level only. In fact, as we have seen, pools 
and lanes are often used to capture coarse-grained resource assignments, e.g. activity 
“Confirm order” is done within the sales department. When it comes to execution, 
we need to define resource assignments for each task and capturing this informa- 
tion via dedicated lanes (potentially one for each task) will just make the diagram 
too cluttered. Electronic data stores are also not directly interpreted by a BPMS, as 
the BPMS assumes the existence of dedicated services that can access these data 
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stores, e.g. an inventory information service that can access the warehouse DB. So 
the BPMS will interface with these services rather than directly with the data stores. 
Also, the state of a data object indicated in the object’s label, e.g. “Purchase order 
[confirmed]”, cannot be interpreted as such by a BPMS. Later we will show how to 
explicitly represent object states so that they can be interpreted by a BPMS. 

Some BPMSs tolerate the presence of these non-executable elements too. If this 
is the case, we suggest to leave these elements in. Especially pools, lanes, message 
flows bearing electronic objects, electronic data stores and annotations will guide 
us in the specification of some execution properties. For example, the Sales lane in 
the order fulfillment model tells us that the participant to be assigned task “Confirm 
order” has to be from the sales department. Other BPMS modeling tools do not 
support these elements, so it is not even possible to represent them in the diagram. 


Exercise 9.9 Consider the loan assessment model that you obtained in Exercise 9.7. 
Identify the modeling elements that cannot be interpreted by a BPMS. 


9.4.3 Complete the Process Model 


Once we have established the automation boundaries of the process and reviewed 
manual tasks, we need to check that our process model is complete. Often business- 
oriented process models neglect certain information because modelers deem it is not 
relevant for the specific modeling purpose, they assume it is common knowledge, 
or simply, they are not aware of it. It may be fine to neglect this information in a 
business-oriented model, depending on the application scenario. However, informa- 
tion that is not relevant in a business-oriented model may be highly relevant for a 
process model to be executed. 

A typical example is when the process model focuses on the “sunny-day”’ sce- 
nario and neglects all negative situations that may arise during the execution of the 
process, working under the assumption that everything will work well. As we saw in 
Chap. 4, the order fulfillment process is indeed subjected to a number of exceptions. 
For example, it may be aborted if the materials required to manufacture the product 
are not available at the suppliers or if the customer sends an order cancellation. So 
we need to make sure that all exceptions are handled using appropriate exception 
handlers. For example, if the order cancellation is received after the product has 
been shipped or after the payment has been received, we also have to compensate 
for these activities by returning the product and reimbursing the customer. Another 
exception that is commonly neglected is that representing an activity that cannot 
complete. What happens if the customer’s address is never received? Or if the ERP 
module for checking the stock availability does not respond? We cannot assume 
that the other party will always respond or that a system will always be functional. 
Similarly, we cannot assume that activities always lead to a positive outcome. For 
example, an order may not always be confirmed. 
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You may be surprised how rarely exceptions are modeled in a business-oriented 
process in practice. Thus, in the majority of cases, such a model will require to be 
completed with these aspects before being executed. 

In this step, we also need to specify all electronic data objects that are required 
as input and output by the tasks of our process. For instance, in Fig. 9.6 there is 
no input data object to task “Request raw materials from Supplier 1(2)”, though 
this task does need the list of raw materials to be ordered. Another example is task 
“Check stock availability’. This task uses the Purchase order as input (to obtain the 
code of the product to be looked up in the Warehouse DB) but does not produce any 
output data to store the results of the search. However, without this information, the 
subsequent XOR-split cannot determine which branch to take (we can now see why 
this is called data-based XOR-split). If you have not noticed the absence of these 
data objects so far, it is probably because you assumed their existence. This is fine 
in a business-oriented model where only aspects relevant to the specific modeling 
purpose are documented, but not in an executable model, where an engine has to run 
the model. So, make sure each activity has the required input and output electronic 
data objects. The principle is that every data object needed by the BPMS engine to 
pass control between activities and to take decisions must be modeled. 

The completed order fulfillment example, including exception handlers and data 
objects that are relevant for execution, is shown in Fig. 9.8.! 


Exercise 9.10 Take the loan assessment model that you obtained in Exercise 9.6 af- 
ter incorporating the revisions from Exercise 9.7. Complete this model with control- 
flow and data-flow aspects relevant for automation. For simplicity, you may disre- 
gard the modeling elements that are not interpretable by a BPMS. 


9.4.4 Bring the Process Model to an Adequate Granularity Level 


There is not necessarily a one-to-one mapping between the tasks in a business- 
oriented model and those in the corresponding executable model. Indeed, we should 
keep in mind that a BPMS is intended to coordinate and manage handovers of work 
between multiple resources (human or non-human). Accordingly, two or more con- 
secutive tasks assigned to the same resource are candidates for aggregation. If this 
was the case, the BPMS would not add value between these two tasks because it 
would not manage any handover. All it would do is to interfere in the work of a 
given resource. For example, a sequence of user tasks “Enter customer name”, “En- 
ter customer policy number” and “Enter damage details”, such that all three tasks 
will be performed by the same claims handler, should be aggregated into a single 
user task “Enter claim”. 


'The content of the sub-processes and some of the elements that cannot be interpreted by a BPMS 
have been omitted for simplicity. 
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completed with control-flow and data-flow as- 
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, though, where we may actually need to keep consecutive 


There are some cases 
tasks separate, despite they are performed by the same resource. For example, in 


Fig. 9.8 The order fulfillment model of Fig. 9.6 


pects relevant for automation 
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Fig. 9.9 The sales process of a B2B service provider 


Fig. 9.7c we have three user tasks within sub-process “Verify degrees validity”: 
“Post documents to agency”, “Receive results from agency” and “Update student 
record”. While these may be performed by the same admin clerk, we do want to 
keep track of when each task has been completed, for the sake of monitoring the 
progress of the application and manage potential exceptions. For example, if the 
results are not received within a given timeframe, we can handle this delay by adding 


an exception handler to task “Receive results from agency”’. 


Exercise 9.11 Are there activities that can be aggregated in the model obtained in 
Exercise 9.10? Hint: candidate tasks for aggregation may not necessarily be con- 
secutive due to a sub-optimal order of tasks in the business-oriented model. In this 
case, you need to resequence the tasks first (see Sect. 8.2.3). 


In a similar vein, if an activity requires more than one resource to be performed, it 
is too coarse-grained, so we should disaggregate it into more fine-grained tasks such 
that these can be assigned to different resources. For example, an activity “Enter and 
approve money transfer’ is likely to be performed by two different participants even 
if they have the same role, in order to enforce separation of duties: first a financial 
officer enters the order, then a different financial officer approves it. 


Exercise 9.12 Figure 9.9 shows the model for the sales process of a business-to- 
business (B2B) service provider. The process starts when an application is received 
from a potential client. The client is then sent information about the available ser- 
vices and a response is awaited either via e-mail or postal mail. When the response 
is received, the next action is decided upon. Either an appointment can be made with 
the client to discuss the service options in person, or the application is accepted or 
rejected right away. If the application is accepted, an offer is sent to the client and at 
the same time the application is filed. If it is rejected, the client is sent a thank-you 
note and let go. If an appointment has to be made, this is done and at the time of the 
appointment, the application is discussed with the client. Then the process continues 
as if the application had been accepted right away. 


1. Identify the type of each task and find ways of linking the manual tasks to a 
BPMS. 
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2. Remove elements that cannot be interpreted by a BPMS. 
3. Complete the model with control-flow and data aspects required for execution. 
4. Bring the resulting model to a granularity level that is adequate for execution. 


Acknowledgement This exercise is adapted from a similar exercise developed by 
Remco Dijkman, Eindhoven University of Technology. 


9.4.5 Specify Execution Properties 


In the last step, we need to specify how each model element is effectively imple- 
mented by the BPMS. For example, take the first service task of our revised order 
fulfillment example: “Check stock availability”. Saying this task requires the pur- 
chase order as input to contact the warehouse ERP system is not enough. We need 
to specify the service provided by the ERP system to check stock levels and its lo- 
cation in the network, the product information in the purchase order that is required 
by this service (i.e. the format of the input object) and the information produced by 
the service (i.e. the format of the output object). These implementation details are 
called execution properties. More, specifically, these are: 


e Process variables, messages, signals and errors 

e Task and event variables and their mappings to process variables 

Service details for service, send and receive tasks, and for message and signal 
events 

Code snippets for script tasks 

Participant assignment rules and user interface structure for user tasks 

Task, event and sequence flow expressions 

BPMS-specific properties 


These properties do not have a graphical representation in the BPMN diagram, 
but are stored in the BPMN 2.0 interchange format. The BPMN interchange for- 
mat is a textual representation of a BPMN model in XML format. It is intended to 
support the interchange of BPMN models between tools and also to serve as input 
to a BPMN execution engine. BPMN modeling tools provide a visual interface to 
edit most of these non-graphical properties, so most of the times you will not need to 
write the XML directly. Still, you will need to understand standard Web technology, 
especially XML, XML Schema (XSD), and be familiar with the notion of (Web) ser- 
vice, to be able to implement a process model. This section assumes that you have 
basic knowledge of these technologies. We provide pointers to further readings on 
these technologies in Sect. 9.8. 

Figure 9.10 shows the structure of the BPMN format. It consists of a list of ele- 
ments, where some are optional (those with a dashed border) and others are manda- 
tory (those with solid borders). The process element is mandatory and stores in- 
formation about the process model. This consists of electronic data objects, events, 
tasks and flows. The elements outside the process are reusable components needed 
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by the various process elements, like message definitions and service interfaces 
which are used by service, send and receive tasks, and by message and signal events. 
With reference to this structure, let us now go through each of the execution proper- 
ties above. 


Process Variables, Messages, Signals and Errors Process variables are man- 
aged by the BPMS engine to allow data exchange between process elements. Each 
electronic data object, e.g. the purchase order in the order fulfillment process, rep- 
resents a process variable. The lifetime of a process variable is confined to the life 
of the process instance in which the variable is created, and is only visible to the 
process level in which it is defined and to all its sub-processes. This means that a 
variable defined in a sub-process is not visible in the parent process. 

We need to assign a data type to each process variable in order for a BPMS to 
be able to interpret and manipulate these variables. In BPMN, the type of each pro- 
cess variable is specified as an XSD type. The type of a variable can be simple or 
complex. Simple types are strings, integers, doubles (numbers containing decimals), 
booleans, dates, times, etc., and are already defined in the XSD specification. For ex- 
ample, the object Stock availability can be represented as a process variable of type 
integer (representing the number of available units of a product). Complex types are 
hierarchical compositions of other types. A complex type can be used for example to 
represent a business document, such as a purchase order or an invoice. Figure 9.1 1a 
shows the complex type of the purchase order, called purchaseOrderType, while 
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a) 


<complexType name="purchaseOrderType"> 
<sequence> 
<element name="order"> 
<complexType> 
<sequence> 


<element name="orderNumber" type="integer"/> 


<element name="orderDate" type="date"/> 
<element name="status" type="string"/> 
<element name="currency" type="string"/> 


<element name="productCode" type="string"/> 


<element name="quantity" type="integer"/> 
</sequence> 
</complexType> 
</element> 
<element name="customer"> 
<complexType> 
<element name="name" type="string"/> 
<element name="surname" type="string"/> 
<element name="address"> 
<complexType> 
<sequence> 


<element name="street" type="string"/> 


<element name="city" type="string"/> 
<element name="state" type="string"/> 


<element name="postCode" type="string"/> 
<element name="country" type="string"/> 


</sequence> 
</complexType> 
</element> 
<element name="phone" type="string"/> 
<element name="fax" type="string"/> 
</complexType> 
</element> 
</sequence> 
</complexType> 
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b) 


<purchaseOrder> 
<order> 
<orderNumber>15664</orderNumber> 
<orderDate>2012-10-23</orderDate> 
<status>confirmed</status> 
<currency>EUR</currency> 
<productCode>345-EAR</productCode> 
<quantity>10</quantity> 
</order> 
<customer> 
<name>John</name> 
<surname>Brown</surname> 
<address> 
<street>8 George St</street> 
<city>Brisbane</city> 
<state>Queensland</state> 
<postCode>4000</postCode> 
<country>Australia</country> 
</address> 
<phone>+61 7 3240 0010</phone> 
<fax>+61 7 3221 0412</fax> 
</customer> 
</purchaseOrder> 


Fig. 9.11 The XSD describing the purchase order (a) and one of its instances (b) 


Fig. 9.11b is the XML representation of a particular purchase order instance at run- 
time. From the type definition we can see that a purchase order contains a sequence 
of two elements: 


e Order, to store the order information (order number, order date, status, currency, 
product code and quantity), and 

e Customer, to store the customer information (name, surname, address, phone and 
fax) 


The data fields order, customer and address are complex types so that they can 
contain sub-elements. Also, observe the field status within order: this is used to 
capture the state of the purchase order, e.g. ““confirmed”’. 

Similar to process variables, we also need to assign data types to each message, 
signal and error used in the process model. For the messages, we can look at the 
existing message flows in the diagram and define one data type for each uniquely 
labeled message flow. So for example if we have two message flows labeled pur- 
chase order, they will obviously take the same type purchaseOrderType. If message 
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flows are not modeled, we can look at the send, receive and service tasks, and at 
the message events present in the diagram in order to understand what messages to 
define. For signals and errors we have to look at the signal and error events that we 
have defined in the diagram. While for a signal, the data type describes the content 
of the signal being broadcasted or listened to, for an error the data type defines what 
information is carried with the error. For example, if it is a system error, we can 
use this to specify the error message returned by the system. In addition, we need 
to assign an error code to each error. This code uniquely identifies an error within 
the process model, so that a catching error event can be related to a throwing error 
event. 


Task and Event Variables Besides the above data elements, we need to define 
the internal variables of each task, called data inputs and data outputs in BPMN. 
Data inputs and outputs act as interfaces between a task and its input and output data 
objects. They also need to refer to an XSD type defining their structure, but different 
from process variables, they are only visible within the task (or sub-process) in 
which they are defined. Data inputs capture data that is required by the task to be 
executed; data outputs capture data that is produced by the task upon completion. 
Thus, data inputs are populated with the content of input data objects while data 
outputs are used to populate the content of output data objects. For example, we 
need a data input for task “Check stock availability” in order to store the content 
of the purchase order. Thus, the type of this data input must match that of the input 
object, i.e. purchaseOrderType. Similarly, the data output must be of type integer to 
store the number of items in stock, so that this information can be copied into stock 
availability upon task completion. 

The mapping between data objects and task data inputs/outputs is defined via the 
task data associations. Data associations can also be used to define complex data as- 
signments beyond one-to-one mappings. For example, consider task “Manufacture 
product”. The service invoked by this task only requires the order product code and 
quantity in order to start the manufacturing of the product. Thus, we can use a data 
association to extract the product code and quantity from the input purchase order, 
and populate a data input containing two sub-elements of types string, respectively, 
integer. In most cases, the BPMS will automatically create all the tedious data map- 
pings between data objects and tasks. For example, for the case above all we need 
to do is to select the sub-elements of the purchase order we want to use as input 
to “Manufacture product’, and the BPMS will create the required data inputs and 
their mappings for this task. BPMN relies on XPATH 1.0 as the default language 
for expressing data assignments like the one above. However, other languages can 
be used like Java Universal Expression Language (UEL) or Groovy. The choice 
depends on the BPMS adopted. For example, Activiti supports UEL, Bonita Open 
Solution and Camunda Fox support Groovy while BizAgi’s BPM Suite supports its 
own expression language. 

Similar to tasks, events that transmit or receive data, i.e. message, signal and 
error events, also have internal variables. Specifically, the catching version of these 
events has one data output only, to store the content of the event being caught (e.g. an 
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incoming message), whereas the throwing version has one data input only, to store 
the content of the event being thrown (e.g. an error). Thus, we also need to assign 
these data inputs and outputs a type that has to match that of the message, signal 
or error associated with the event. For example, the start catching message event 
“Purchase order received” in the order fulfillment example uses a data output to store 
the purchase order message once this has been received. Thus, this data output must 
match the type of the incoming message, which is precisely purchaseOrderType. In 
turn, the output object must have the same type as the output data, to contain the 
purchase order. 

The complex types for all data elements of the process can be defined directly in 
the BPMN model or imported from an external document (see Fig. 9.10). 


Service Tasks Once we have defined the types of all data elements, and mapped 
task and event data inputs and outputs to these types, we have to specify how tasks 
and events have to be implemented. For service tasks we need to specify how to 
communicate with the external application that will execute the task. Be it a com- 
plex system or a simple application, from the perspective of the BPMS all that is 
required is that the external application provides a service interface that the service 
task can use. A service interface contains one or more service operations, each de- 
scribing a particular way of interacting with a given service. For example, a service 
for retrieving inventory information provides two operations: one to check the cur- 
rent stock levels and one to check the stock forecast for a given product (based on 
product code or name). An operation can either be in-out or in-only. In an in-out 
operation (also called synchronous operation), the service expects a request mes- 
sage and replies with a response message once the operation has been completed, 
or optionally with an error message if something goes wrong. For example, the ser- 
vice invoked by task “Check raw materials availability” receives stock availability 
information as input message and replies with a list of raw materials to be ordered 
as output message. Alternatively, if the service experiences an exception (e.g. the 
suppliers catalog is unreachable), it replies with an error message which triggers 
the boundary error event of this task so that the relative exception handler can be 
performed.” Conversely, in an in-only operation (also called asynchronous opera- 
tion), the service expects a request message but will not reply with a response mes- 
sage. For example, task “Archive order” notifies an archival service of the purchase 
order to be archived, however, the process does not wait for an archival confirma- 
tion. 

Each message of a service operation needs to reference a message in the BPMN 
model, so that it can be assigned a data type. For instance, the request and the re- 
sponse messages to interact with the inventory service have data type purchase- 
OrderType, respectively, XSD integer. For each interface, we also need to specify 
how this is concretely implemented, i.e. what communication protocols are used by 


?Note that there is no throwing end error event inside “Check raw materials availability” since the 
catching error event is triggered by the receipt of an error message by the service task. The ability 
to link error messages with error events is a common feature of BPMSs. 
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the service and where the service is located in the network. By default, BPMN uses 
Web service technology to implement service interfaces, and relies on WSDL 2.0 
to specify this information. In practice, this corresponds to defining one or more 
external WSDL documents and importing them into our BPMN model. Once again, 
other implementations are possible, e.g. one could implement a service interface via 
Java remote procedure call or plain XML over HTTP. 

After defining the service interfaces for our process, we need to associate each 
service task with a service operation defined in a service interface. Based on the type 
of the operation (in-out or in-only), we then need to define a single data input that 
must match the type of the request message in the referenced service operation, and 
optionally a single data output that must match the type of the response message in 
the operation. The BPMS engine will copy the task data input to the request message 
and send it out to the service, and once the response message has been received, will 
copy the content of this message to the task data output. 


Send and Receive Tasks, Message and Signal Events Send and receive tasks 
work similarly. A send task is a special case of the service task: it sends a message 
to an external service using its data input, but there is no response. An example 
is task “Notify unavailability to customer”. A receive task waits for an incoming 
message and uses its data output to store the message content. Task “Get shipping 
address” is an example of this. Both task types need to reference an in-only service 
operation where the message is defined. However, for the receive, the message being 
received is seen as a request coming from an external service requester. Thus, in this 
case the process itself acts as the service provider. 

A receive task can also be used to receive the response of an asynchronous ser- 
vice which has previously been invoked with a send task. This is the case of tasks 
“Request shipping address” and “Get shipping address”. The asynchronous service 
is provided by the customer. Accordingly, in the send task the seller’s process acts 
as the service requester sending a request message to the customer. In the receive 
task the roles get swapped: the seller acts as the service provider to receive the 
response message from the customer. This pattern is used for long-running interac- 
tions, where the response may arrive after a while. The drawback of using a syn- 
chronous service task in place of a send-receive is that this task would block the 
process to wait for the response message. This is not the case in Fig. 9.8, where the 
send and receive tasks are in parallel to “Emit invoice” which may thus be performed 
in-between. 

Message and signal events work exactly like send and receive tasks. For signal 
events, it is assumed that the service being contacted has publish-subscribe capabil- 
ities, e.g. a Web service for subscribing to RSS feeds. 


Script Tasks For script tasks, we need to provide the snippet of code that will 
be executed by the BPMS. This code can be written in a programming language 
such as JavaScript or Groovy. BPMN does not prescribe the use of a specific pro- 
gramming language so the choice depends on the BPMS used. The task data inputs 
store the parameters for invoking the script while the data outputs store the results 
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of executing the script. For example, for task “Determine cancellation penalty” we 
can define a script that extracts the order date and the cancellation request date from 
two data inputs mapped to the input objects purchase order and cancellation request, 
uses this information to compute a penalty of €15 for each day past the order date, 
and copies this value to the data output. 


User Tasks For each user task we need to specify the rules for assigning work 
items of this task to process participants at runtime, the technology to communicate 
with participants and the details of the user interface to use. Moreover, like for any 
other task, we need to define data inputs to pass information to the participant, and 
data outputs to receive the results. 

Process participants that can be assigned user tasks are called potential owners 
in BPMN. A potential owner is a member of a resource class. In the context of user 
tasks, a resource class identifies a static list of participants sharing certain charac- 
teristics, e.g. holding the same role or belonging to the same department or unit. 
An example of resource class for the order fulfillment process is order clerk, which 
groups all participants holding this role within the sales department of the seller or- 
ganization. Note that these resource classes are unrelated to pools and lanes, which 
are only notational elements in a business-oriented process model. A resource class 
can be further characterized by one or more resource parameters, where a parameter 
has a name and a data type. For example, we can define two parameters product and 
region of type string to indicate the particular products an order clerk works with, 
and the region they work in. 

Once we have defined all required resource classes and optionally their param- 
eters, we can assign each user task to one or more resource classes based on an 
expression. For example, we can express that work items of task “Confirm order” 
have to be assigned to all participants of type Order clerk who deal with the partic- 
ular product being ordered and work in the same region as the customer. For this, 
we can define an XPATH expression that selects all members of Order clerk whose 
properties product and region are equal to the product code, respectively, country 
contained in the purchase order. 

We also need to specify the implementation technology used to offer the work 
item to the selected participant(s). This entails aspects such as how to reach the 
participant (e.g. via email or worklist notification), how to render the content of 
the task data inputs on screen (e.g. via one or more web forms organized through a 
particular screenflow), and the strategy to assign the work item to a single participant 
out of those satisfying the assignment expression (e.g. assign it to the order clerk 
with the shortest queue or randomly). The configuration of these aspects, as well as 
the association of participants to resource classes is dependent on the specific BPMS 
being used. 


Task, Event and Sequence Flow Expressions — Finally, we need to write expres- 
sions for the various attributes of tasks and events, and for the sequence flows bear- 
ing conditions. For instance, in a loop task we need to write a boolean expression 
that implements the textual annotation indicating the loop condition (e.g. “until re- 
sponse approved’). This boolean expression will determine when will the loop task 
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be repeated. This expression can be defined over data elements, e.g. it can be an 
XPATH expression that extracts the value of the boolean element “approved” from 
a Response object. We can also use instance attributes inside these expressions. 
These are variables that vary by instance at execution. An example is loop count, 
which counts the number of iterations for a loop task. For the timer event we need 
to specify an expression to capture the temporal event informally expressed by its 
label (e.g. “Friday afternoon’). Here we have three options: we can either provide 
a temporal expression in the form of a precise date or time, a relative duration, or a 
repeating interval. Once again, these expressions can be linked to data elements and 
instance properties so as to be resolved dynamically at execution. For example, we 
can set an order confirmation timeout based on the number of line items in an order. 
Finally, we need to write a boolean expression to capture the condition attached to 
each sequence flow following an (X)OR-split. For example, condition “product in 
stock” after the first XOR-split in the order fulfillment example can be implemented 
as an XPATH expression that checks whether the value of variable stock availability 
is at least equal to the product quantity contained in the purchase order. There is no 
need to assign an expression to a default sequence flow, since this arc will be taken 
by the BPMS engine if the expressions assigned to all other arcs emanating from 
the same (X)OR-split evaluate to false. 


BPMS-Specific Properties Strictly speaking, the only BPMS-specific proper- 
ties that we have to configure in order to make a process model executable are 
those of user tasks. In practice, however, we will likely need to link our executable 
process with the enterprise system of our organization. This is called system bind- 
ing. Luckily, BPMSs offer a range of predefined service task extensions, called ser- 
vice adaptersservice adapter (or service connectors), to implement common system 
binding functions in a convenient way. Examples of such binding functions include: 
performing a database lookup, sending an email notification, posting a message to 
Twitter or setting an event in Google Calendar, reading or writing a file and adding 
a customer in a CRM system. Each adapter comes with a list of parameters that 
we need to configure. However, BPMSs provide wizards with capabilities to auto- 
discover some of the parameter values. For instance, to use a database lookup we 
need to provide the type of the database server (e.g. MySQL, Oracle DB) and the 
URL where the server can be reached, the schema to be accessed, the SQL query to 
run and the credentials of the user authorized to run the query. 

Coming back to our example, instead of implementing task “Check stock avail- 
ability” as a service task, which assumes the existence of an inventory information 
service at the seller, we could implement this task with a generic database lookup 
adapter, provided we know what to search for and where. Similarly, we could im- 
plement the tasks for communicating with the customer like “Notify unavailability 
to customer” and “Request shipping address” as email adapters, so that we do not 
need to implement a dedicated email service in our organization. The number and 
variety of adapters that a BPMS provides largely contribute to increasing the value 
of the product over competing solutions. 
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Exercise 9.13 Consider the loan assessment process model that you obtained in 
Exercise 9.11. The loan application contains these data fields: 


e Applicant information: 
— Identity information (name, surname, ...) 
Contact information (home phone, cell phone, ...) 
— Current address (street name and number, city, ...) 
Previous address (as above plus duration of stay) 
— Financial information (job details, bank details) 
e Reference information (identity, contact, address, relation to applicant) 
e Property information (property type, address, purchasing price) 
Loan information (amount, number of years, start date, interest type: vari- 
able/fixed) 
Application identifier 
Submission date and time 
Revision date and time 
Administration information (a section to be compiled by the loan provider): 
— Status (a string to keep track of the state of the application, with predefined 
values: “incomplete”, “complete”, “assessed”, “rejected”, “canceled”, “ap- 
proved’) 
Comments on status (optional, e.g. used to explain the reasons for rejection) 
— Eligibility (a boolean to store whether or not the applicant is eligible for a loan) 
Loan officer identifier 
— Insurance quote required (a boolean to store whether or not a home insurance 
quote is sought) 


The credit history report contains these data fields: 


Report identifier 

Financial officer identifier 

Reference to a loan application 

Applicant’s credit information: 

— Loan applications made in the last five years (loan type: household/personal/ 
domestic, amount, duration, interest rate) 

— Overdue credit accounts (credit type, default amount, duration, interest rate) 

— Current credit card information (provider: Visa, Mastercard, ..., start date, end 
date, interest rate) 

— Public record information (optional, if any): 
e Court judgments information 
e Bankruptcy information 

e Credit assessment (a string with predefined values: AAA, AA, A, BBB, BB, B 

unrated). 


The risk assessment contains the following data fields: 


e Assessment identifier 
e Reference to a loan application 
e Reference to a credit history report 
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e Risk weight (an integer from 0 to 100) 
The property appraisal contains the following data fields: 


Appraisal identifier 

Reference to a loan application 

Property appraiser identifier 

Property information (property type, address) 

Value of three surrounding properties with similar characteristics 

Estimated property market value 

Comments on property (optional, to note serious flaws the property may have) 


The agreement summary contains the following data fields: 


e Reference to a loan application 

e Conditions agreed (a boolean indicating if the applicant agreed with the loan con- 
ditions) 

e Repayment agreed (a boolean indicating if the applicant agreed with the repay- 
ment schedule) 

e Link to digitized copy of the repayment agreement 


The loan provider offers a website where applicants can submit and revise loan 
applications online, track the progress of their applications and if required, cancel 
applications in progress. This website implements an underlying Web service with 
which the loan assessment process interacts. In practice, this service acts as the 
applicant from the perspective of the loan assessment process. For example, if the 
applicant submits a new loan application through the website, this service wraps this 
application into a message and sends it to the BPMS engine of the loan provider, 
which in turn starts a new instance of the loan assessment process. If the loan as- 
sessment process sends an application for review to this service, the service presents 
this information to the applicant via the loan provider’s website. 

Further, the loan assessment process interacts with an internal service for assess- 
ing loan risks. This service determines a risk weight which is proportional to the 
credit assessment contained in the credit history report, on the basis of the appli- 
cable risk rules read from a database (the interaction between the service and the 
database is transparent to the BPMS). The risk assessment service returns a risk 
assessment containing an identifier (freshly generated), a reference to the loan ap- 
plication and one to the credit history report (both extracted from the credit history 
report), and the risk weight. 

Based on the above information, specify the execution properties for the elements 
of this process model. You are not required to define the actual XSD type of each 
data element, nor to specify the actual Groovy scripts or XPATH expressions. All 
you need to do is to identify what properties have to be specified, i.e. what data 
inputs and outputs, service interfaces, operations, messages and errors are required, 
and determine their data type in relation to that of process variables. For example, a 
data input may map to a process variable or to a data field within this. For scripts, 
you need to define via task data inputs and outputs what data is required by the 
script, what data is produced and how the input data is transformed into the output 


9.4 Turning Process Models Executable 337 


one. For example, based on the value of a data field in a process variable, a script 
may write a particular value in the data field of another process variable. Similarly, 
for each user task, you need to identify what information is presented to the task 
performer, and how the data output is obtained. Finally, you need to explain how 
each expression can be evaluated on the basis of data fields within process variables 
(e.g. to implement the condition of a sequence flow), or constant values like a date 
(e.g. to implement a timer event). 


9.4.6 The Last Mile 


Now that you have become familiar with what is required to turn a process model 
executable, the last step for you is to take a process model and implement it us- 
ing a BPMS of your choice (e.g. Activiti, Bonita Open Solution, Bizagi’s BPM 
Suite, YAWL). The landscape of BPMSs and their specificities evolves continu- 
ously. We can identify three categories of BPMSs with respect to their support for 
BPMN: 


1. Pure BPMN These tools have been designed from the ground up to support 
BPMN natively. They follow the specification “to the letter” though they might 
not fully support it. Examples are Activiti and Camunda Fox. 

2. Adapted BPMN These tools use a BPMN skin but rely on an internal rep- 
resentation to execute the process model. They can import and sometimes also 
export in the BPMN 2.0 format. They typically predate BPMN and evolved from 
previous versions to support the specification. Examples are Bizagi’s BPM Suite 
and Bonita Open Solution. 

3. Non BPMN There is finally a general category of BPMSs which use their own 
proprietary language and semantics. These tools do not support BPMN. Exam- 
ples are BPMOne from Perceptive Software and YAWL. 


At the time of writing, most of the BPMSs supporting BPMN in one way or 
another, still do not cover all aspects of the specification that are relevant for execu- 
tion. For example, elements like message boundary events, compensation events and 
non-interrupting events are hardly supported. So concretely we have to give up on 
one or more of these elements depending of the BPMS that we adopt. One expects 
though that support for executable BPMN will increase over time. 

This section illustrated how to design executable BPMN models in a vendor- 
independent manner. The book’s website (http://fundamentals-of-bpm.org) pro- 
vides tutorial notes showing how to configure an executable process model for con- 
crete BPMSs. 


Exercise 9.14 Based on the execution properties that you specified in Exercise 9.13, 
implement the loan assessment process using a BPMS of your choice. 
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9.5 Recap 


In this chapter we focused on a specific type of process-aware information sys- 
tem, namely Business Process Management Systems (BPMSs). We discussed the 
architecture of a BPMS and its main components: the execution engine, the process 
modeling tool and the process model repository, the administration and monitoring 
tools and the execution logs, as well as the external services that can be invoked. 

There are many reasons for considering process automation. First, it provides 
workload reduction in terms of coordination: work is assigned to process partici- 
pants or software services as soon as it is available. Second, it offers integration 
flexibility. Processes can be changed with significantly less effort as compared to 
legacy systems, provided they are explicitly represented via process models. Third, 
the execution ina BPMS generates valuable data on how processes are executed, in- 
cluding performance-relevant data. Finally, BPMSs improve the quality of process 
execution as they directly enforce rules such as separation of duties. 

Introducing BPMSs poses various challenges. Technical challenges arise from 
the fact that many applications that have to be integrated are typically not designed 
as open systems with transparent interfaces. Beyond that, organizational challenges 
are rooted in the fact that BPMSs directly interfere with how people do their job. 
This fact calls for sensitive change management. 

Finally, we presented a method for transforming business-oriented process mod- 
els into executable specifications, so that they can be interpreted by a BPMS. First, 
we need to identify the type of each process task (automated, manual or user) and re- 
view manual tasks to find, whenever it is possible, a way to link these to the BPMS. 
Next, we need to complete the process model by specifying all control-flow and 
data aspects that are relevant for execution and bridge the diverging level of gran- 
ularity between a business-oriented process model and its executable counterpart. 
Finally, we need to specify a number of execution properties for each model ele- 
ment. Some of these properties, like for user tasks, are vendor-specific and so will 
vary depending on the specific BPMS that we decide to adopt. 


9.6 Solutions to Exercises 


Solution 9.1 There are three current work items: 


1. Case #1,220: Determine Proper Piece of Equipment 
2. Case #1,230: Determine Proper Piece of Equipment 
3. Case #1,240: Complete Equipment Rental Request 


Solution 9.2 


e The execution engine would be unable to determine to allocate work items to 
resources on the basis of a process model alone, when it would only cover control- 
flow information. 
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e One common situation would be that the process model in question specifies that 
after a certain activity there is a parallel split, enabling the execution of various 
follow-up activities. 

e Other examples of services that can be useful to be invoked: calculation services 
(e.g. to determine a mortgage rate or to estimate the total cost of a service), infor- 
mation storage and retrieval services (e.g. to register the outcome of a completed 
work item or to look up client information), scheduling services (e.g. to plan work 
that is to be done in follow-up or to estimate a delivery date), communication ser- 
vices (e.g. to get in touch with the client or a business partner), etc. 

e The descriptions of the business processes and the available kinds of resource 
should exactly be the same to allow for passing on work items among different 
BPMSs. Otherwise, it may become impossible to map the availability of a work 
item within a process in one time zone to a particular state of that process in 
another time zone. 

e Most notably, it would be important to specify on which working days particular 
resources are available and during which hours, e.g. Ms. Withagen only works on 
Mondays and Fridays from 9 AM to 4 PM. In this way, it becomes possible for 
the execution engine to allocate work items in an efficient manner. 


Solution 9.3 


1. It should become possible that the new decision support system can be invoked 
as an external service. 

2. If Ms. Withagen retires, this must be recorded with the administration tool. 

3. The new rule to allocate work items to resources must be captured in an updated 
process model. 

4. The monitoring service must be implemented in a monitoring tool. 


Solution 9.4 


e Quality 
e Transparency 
e Flexibility 


Solution 9.5 


1. Organizational issue: BPMSs can be highly tailored to take patient-specific data 
into account. 

2. Technical issue: The integration of the decision support system may require ad- 
ditional, customized software development. 

3. Organizational/technical: The nurses may one the one hand get accustomed to 
using the BPMS in general and worklist handlers specifically. On the other hand, 
it may not be a good technical solution to use vibration signals—an alternative 
would be, for example, to use sound signals. 
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Solution 9.6 
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Solution 9.7 All five manual tasks of this process, namely “Appraise property”, 
“Prepare acceptance pack”, “Send acceptance pack’, “Send home insurance quote” 
and “Verify repayment agreement” can be implemented as user tasks. In “Appraise 
property”, the property appraiser is notified through their worklist that they have 
to appraise a new property. The information on the property is carried by the work 
item of this task (e.g. property type and address). The property appraiser physically 
goes to the property address for an inspection and checks the value of surrounding 
properties. Once done, he prepares the appraisal on an electronic form and submits 
it to the BPMS engine via the worklist handler. “Prepare acceptance pack”, “Send 
acceptance pack’, “Send home insurance quote” can be implemented as user tasks 
in a similar way. 

“Verify repayment agreement” appears in the loan officer’s worklist as soon as 
the acceptance pack, and optionally the insurance quote, have been sent to the ap- 
plicant. The officer checks out this work item once they have received the repay- 
ment agreement from the applicant by post. They manually verify the agreement, 
digitize it and attach it as a file to the agreement summary—an electronic form as- 
sociated with this work item and pre-populated with information extracted from the 
loan application. If the applicant accepted all loan conditions and agreed with the 
repayment schedule, the officer ticks the respective checkboxes in the agreement 
summary and submits this to the BPMS engine. 


Solution 9.8 Task “Check insurance” can be automated through a service that de- 
termines the amount of the co-payment based on the details of the prescription and 
on the customer’s insurance policy. 

Tasks “Collect drugs from shelves” and “Check quality” are manual tasks. These 
tasks can be implemented as user tasks in the automated process. To do so, the phar- 
macy technician who collects the drugs, and the pharmacist who quality-checks the 
prescription and seals the bag, should have a convenient mechanism to signal the 
completion of these activities to the BPMS. This could be achieved by putting in 
place a system based on barcode scans to track prescriptions. For example, the tech- 
nician would see a list of prescriptions to be filled from their worklist. They would 
then pick up one of the prescriptions and the system would associate the prescrip- 
tion to a new barcode which is printed on an adhesive label. The technician would 
then attach the label to a bag, collect the drugs and put them in a bag, and when 
done, they would scan the barcode from the label to record that the prescription has 
been fulfilled. This signals the completion of task “Collect drugs from shelves” to 
the pharmacy system. In turn, it generates a new work item of task “Check quality” 
in the pharmacist’s worklist. The pharmacist can then quality-check the prescription 
and scan the barcode again. 

Task “Collect payment” is also a manual task. This task could be implemented 
as a service task whereby the pharmacy system would push the task of collecting 
the payment for a prescription to a Point-of-Sale (POS) system and expect the POS 
system to indicate that the payment has been collected. The pharmacy technician 
would interact with the POS system once the customer arrives, but this interaction 
is outside the scope of the pharmacy system. The pharmacy system merely pushes 
work to the POS system and waits for completion. 
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Fig. 9.12 The automated prescription fulfillment process 


The description of the process implicitly refers to a manual task whereby the 
pharmacist seals the bag and puts it into the pick-up area. However, this “Seal bag” 
task is not included in the executable process model. Instead, this task is integrated 
into the “Check quality” task. In other words, at the end of the quality check, the 
pharmacist is expected to seal the bag if the prescription is ready and drop the bag 
in the pick-up area. 

Task “Retrieve prescription bag” is also manual but there is no value in automat- 
ing it in any way. So this task is left out of the executable process model, which 
completes once the payment has been made. 


The executable model of the entire prescription fulfillment process is illustrated 
in Fig. 9.12. 


Solution 9.9 


e Physical data objects: Acceptance pack (this is the loan offer on paper), Repay- 
ment agreement (this is signed by the applicant on paper and has been replaced by 
the Agreement summary, an electronic document containing a link to a digitized 
copy of the repayment agreement plus a reference to the loan application). We 
assume all other communications between applicant and loan provider to occur 
via e-mail 

e Messages carrying physical objects: Acceptance pack, Repayment agreement, 
Home insurance quote (the quote is sent on paper) 

e Data stores: Risk Rules DB 

e States of data objects 

e Pools and lanes 
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Note that a work item of task “Verify repayment agreement” automatically disap- 
pears from the loan officer’s worklist if the officer does not start it within two weeks. 
This happens if the officer has not received the repayment agreement by post within 
that timeframe. 


Solution 9.11 It makes sense for tasks “Prepare acceptance pack” and “Send ac- 
ceptance pack” to be performed by the same loan officer. However, task “Check 
if home insurance quote is requested” is meant to be executed between these two 
tasks. Since there is no temporal dependency between “Check if home insurance is 
requested” and the other two tasks, we can postpone the former to after “Send ac- 
ceptance pack” or parallelize it with the other two tasks. This way we can aggregate 
the two consecutive tasks into “Prepare and send acceptance pack”’. 


Solution 9.12 The solution is shown in Fig. 9.13. 


1. Task types: the manual task of this process is “Discuss application”. This can 
be implemented as a user task that completes by producing a recommendation. 

2. Non-executable elements: all elements can be interpreted by a BPMS. Note that 
the catching message event “Response received by post” assumes the existence 
of an internal service at the service provider that notifies the process when the 
response has been received by post. 

3.1. Missing control flow: task “Create electronic response” is needed to convert the 
response received by post into an electronic version that can be consumed by 
a BPMS. Task “Assess response” may be interrupted by a request to cancel the 
application, for which the process is aborted. This request may also be received 
during the acceptance handling, in which case tasks “Send offer” and “File 
application” need be compensated. A one-week timeout is added to receive the 
response. 
3.2. Missing data: all electronic data objects were missing in the conceptual model. 

4. Granularity level: task “Make appointment” has been disaggregated to explic- 
itly model the task of notifying the client of the result. Similarly, “Send offer” 
and “Send rejection” have been disaggregated to model the preparation of the 
offer, respectively, the rejection letter. Given that “Send offer” has been split 
into two activities (“Make offer’ and “Send offer’) each needs to be compen- 
sated if a cancellation request is received. 


Solution 9.13 We need two service interfaces to interact with the Web service be- 
hind the loan provider’s website. One interface where the loan provider acts as the 
service provider and the other where the website service acts as the service provider. 
The former interface contains one in-only operation for the loan provider to receive 
the initial loan application. The latter interface contains the following four opera- 
tions for the website service: 


© an in-out operation to receive the assessed loan application (containing change 
requests), and to respond with the revised loan application (where changes have 
been made) 
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Fig. 9.13 The model for the sales process of a B2B service provider, completed with missing 


control flow and data relevant for execution 
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e an in-only operation to receive the rejected loan application 
e an in-only operation to receive the approved or canceled loan application 


The four operations above require five messages in total, all of the same data type 
as the loan application’s. These operations are assigned to the start message event, 
the four send tasks and the receive task of the process, which need to have suitable 
data inputs and outputs to contain the loan application. The mapping of these data 
inputs and outputs to data objects is straightforward, except for the send task “Reject 
application”, which needs to modify the status of the loan application to “rejected” 
while copying this input data object into the task data input. 

A third service interface is required to interact with the service for assessing 
loan risks in task “Assess loan risk”. This interface has an in-out operation with 
two messages: an input message to contain the credit history report and an output 
message for the risk assessment. 

The script for task “Check application form completeness” takes a loan applica- 
tion as input and checks that all required information is present. Depending on the 
outcome of the check it changes the application status to either “complete” or “in- 
complete’, assigns a fresh application identifier to the application if empty, writes 
the submission or revision date and time and, if applicable, fills out the status com- 
ments section with pointers to incomplete data fields. The script task “Check if home 
insurance quote is requested” is actually not needed. While in a business-oriented 
model it is important to explicitly capture each decision with an activity as we have 
illustrated in Chap. 3, in an executable model this can be directly embedded in the 
conditions of the outgoing arcs of an (X)OR-split if the outcome of the decision can 
easily be verified. In fact, our example just requires to check the value of a boolean 
field in the application, which can be achieved with an XPATH expression directly 
on the arc labeled “quote requested”. 

All user tasks of this process are implemented via the worklist handler of the 
loan provider and offered to participants having the required role (e.g. task “Assess 
eligibility” is offered to a participant with role loan officer). This implementation 
depends on the BPMS adopted. The mapping between data objects and data inputs 
and outputs for these tasks is straightforward. In the case of task “Assess eligibility”, 
at runtime the loan officer will see an electronic form for the loan application (ed- 
itable), and two more forms for the risk assessment and for the property appraisal 
(non editable). The officer is required to edit the loan application by entering their 
identifier, specifying whether or not the applicant is eligible for the loan and adding 
status comments in case of ineligibility. The other user tasks work similarly. 

We have already discussed how to implement the condition of arc “quote re- 
quested”. The conditions on the other sequence flows can be implemented with an 
expression that extracts data from a data object in a similar way. The expression for 
the arc labeled “always” is simply “true” as this arc is taken always. The tempo- 
ral expression for the two timer events is simply a relative duration (5 days and 2 
weeks). 
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Solution 9.14 This is a hands-on exercise, no solution is provided. Resources re- 
lated to implementing processes on top of specific BPMSs can be found in the com- 
panion website http://fundamentals-of-bpm.org. 


9.7 Further Exercises 
Exercise 9.15 Draw the architecture of a BPMS and identify all its components. 


Exercise 9.16 Explain the similarities and differences between production and ad- 
hoc workflow systems. Include in your explanation a reflection on the type of sup- 
port they provide on the one hand and their orientation in the spectrum of data versus 
process on the other. 


Exercise 9.17 Classify the following objectives of the various organizations de- 
scribed that use a BPMS and use the categories that were explained in Sect. 9.2. 


e A legal company wishes to track all the participants it has involved in its formal- 
ized process for the preparation of litigation cases. 

e A governmental agency wishes to reduce the penalties it must pay for late pay- 
ments of invoices. 

e A bank wishes to demonstrate to its external auditor that it strictly enforces the 
principle that each large loan is approved by two separate clerks. 


Exercise 9.18 In a 2009 posting on LinkedIn, the director of Walgreens, an on- 
line pharmacy, asks what the common pitfalls are when implementing a workflow 
management system. A consultant at Microsoft answers as follows: 


It’s really all about people buying in to the system. The general tendency of people is that 
they don’t like change, even if they say they do. Even if their current processes are very 
inefficient, they know how it works. So when you introduce something that changes their 
world (with a workflow mgt system), they’Il be very apprehensive. Also, the more the sys- 
tem changes how they do their job, the more resistance you'll get. Then it becomes an issue 
of how you gathered your business requirements. Chances are that due to misunderstandings 
the requirements will be different from expectations of how things should get done. 


Explain whether you think this explanation relates to a technical or an organiza- 
tional challenge. 


Exercise 9.19 Identify the type of the tasks in Fig. 4.15, and represent them using 
appropriate BPMN markers. 


Exercise 9.20 Consider the following business processes. Identify which of these 
models can be automated and justify your choice. 


1. Recruiting a new soldier. 
2. Organizing a court hearing. 
3. Buying an item at an auction on eBay. 
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Fig. 9.14 FixComp’s process model for handling complaints 


Managing inventory assets disposition. 

Booking a trip on-line. 

Handling an IT-system maintenance job. 

Servicing a used car at a mechanic. 

Making online trade customs declarations. 

Processing employee payrolls. 

Synchronizing data servers in a distributed environment. 


SNe ON 


Exercise 9.21 Figure 9.14 shows the process model that FixComp follows when a 
client files a complaint. Upon receipt of a new complaint from a client, the process 
starts by sending an automatic reply to the client, in order to reassure them that Fix- 
Comp is following up on their request. A complaints representative then takes the 
complaint for discussion with people in the department the complain refers about. 
Next, the complaints representative sends a personal letter of apology to the client 
and propose them a solution. The client can either accept or reject the solution. If 
the client accepts the solution, the solution is executed by the relevant department. 
If the client rejects the solution, the client is called on the phone to discuss possible 
alternatives by the complaints representative. If one of these alternatives is promis- 
ing, it is discussed with the department and the process continues. If no agreement 
can be reached, the case is brought to court. 

The company wants to automate this process to deal with complaints in a more 
efficient manner. Your task is to prepare this model for execution. 


Acknowledgement This exercise is adapted from a similar exercise developed by 
Remco Dijkman, Eindhoven University of Technology. 


Exercise 9.22 Consider the claims handling process modeled in Fig. 9.15. Imple- 
ment this business process using a BPMS of your choice. 

The process starts when a customer submits a new insurance claim. Each insur- 
ance claim goes through a two-stage evaluation process. First of all, the liability of 
the customer is determined. Secondly, the claim is assessed in order to determine if 
the insurance company has to cover this liability and to what extent. If the claim is 
accepted, payment is initiated and the customer is advised of the amount to be paid. 
All activities except “Initiate Payment” are performed by claims handlers. There 
are three claims handlers. Activity “Initiate Payment” is performed by a financial 
officer. There are two financial officers. 
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Fig. 9.15 Claims handling process model 


As shown in the model, there are two data objects involved in this process: Claim 
and Claim decision. A claim includes the following data fields: 


Name of claimant 

Policy number (a string with alphanumeric characters) 
Description of the claim 

Amount claimed 


A claim decision consists of the following data fields: 


Reference to a claim 

Decision (positive or negative) 

Explanation 

Amount to be reimbursed (greater than zero if the decision is positive) 


You may add other data fields into the above objects if you deem it necessary. 


Exercise 9.23 Consider the following equipment rental process, which is a variant 
of the one described in Example 1.1. Implement this business process using a BPMS 
of your choice. 

The rental process starts when a site engineer fills in an equipment rental request 
containing the following details: 


Name or identifier of the site engineer who initiates the request 
Requested start date and time of the equipment rental 
Expected end date and time of the equipment rental 

Project for which the equipment is to be rented 

Construction site where the equipment will be used 
Description of required equipment 

Expected rental cost per day (optional) 

Preferred supplier (optional) 

Supplier’s equipment reference number (optional) 

Comments to the supplier (optional) 
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The rental request is taken over by one the clerks at the company’s depot. The 
clerk consults the catalogs of the equipment suppliers and calls or sends e-mails 
to the supplier(s) in order to find the most cost-effective available equipment that 
complies with the request. Once the clerk has found a suitable piece of equipment 
available for rental, they recommend that it be rented. At this stage, the clerk must 
add the following data to the equipment rental request: 


e Selected supplier 
e Reference number of the selected equipment 
e Cost per day 


Equipment rental requests have to be approved by a works engineer (who also 
works at the depot). In some cases, the works engineer rejects the equipment rental 
request, meaning that no equipment will be hired. Of course, before rejecting a 
request in this way, the works engineer should first discuss their decision with the 
site engineer and also add an explanatory note to the equipment rental request. In 
other cases, the works engineer rejects the recommended equipment (but not the 
entire request) and asks the clerk to find an alternative equipment. Again, in this 
case the works engineer should communicate their decision to the clerk and add an 
explanatory note. 

Rental requests where the cost per day is below 100 are automatically approved, 
without going through a works engineer. 

Once a request is approved, a purchase order is automatically generated from the 
data contained in the approved rental request. The purchase order includes: 


Supplier’s equipment identification 

Cost per day 

Construction site where the plant is to be delivered 
Delivery date and time 

Pick-up date and time 

Comments to the supplier (optional) 


The supplier delivers the equipment to the construction site at the required date. 
The site engineer inspects the equipment. If everything is in order, they accept the 
equipment, add the date of delivery to the purchase order and optionally a note to 
indicate any issues found during the inspection. Similarly, when the equipment is 
picked up by the supplier at the end of the renting period, another inspection is 
performed, and the supplier marks the pick-up date in the purchase order (possibly 
with a pick-up note). 

Sometimes, the site engineer asks for an extension of the rental period. In this 
case, the site engineer writes down the extended pick-up time into the purchase 
order, and the revised purchase order is automatically resent to the supplier. Prior to 
doing this change, the site engineer is expected to call the supplier in order to agree 
on the change of pick-up date. 

A few days after the equipment is picked up, the supplier sends an invoice to the 
clerk by e-mail. The clerk records the following details: 
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Supplier’s details 

Invoice number 

Purchase order number 
Equipment reference number 
Delivery date and time 
Pick-up date and time 

Total amount to be paid 


Having entered these invoice details, the clerk verifies the invoice details against 
the purchase order and marks the invoice as accepted or rejected. In case of 
rejection, the clerk adds an explanatory note (e.g. requesting the supplier to 
send a revised invoice). Eventually, the supplier may send a revised invoice if 
needed. 

The accepted invoice is forwarded to the finance department for payment, 
but this part of the process is handled separately and is not part of this exer- 
cise. 


Exercise 9.24 Define appropriate data types for the sales process shown in 
Fig. 9.13, and implement it using a BPMS of your choice. 


Exercise 9.25 Define appropriate data types for the process shown in Figs. 4.32— 
4.34, and implement it from the perspective of BestLoans using a BPMS of your 
choice. 


9.8 Further Reading 


Van der Aalst and van Hee’s book [95] offers an introduction to workflow man- 
agement technology as of the early 2000s. The evolution from workflow man- 
agement systems to BPMSs that took place during the 2000s is discussed at 
length by Weske [106]. As stated in this chapter, the WfMC reference model 
was instrumental in shaping the architectures of workflow management systems 
and later that of BPMSs. Details on the WfMC reference model can be found at 
http://wfmc.org/reference-model.html while Hollingsworth [34] gives a summary 
of the development and directions of this reference model. 

A frequent critique of BPMSs is that they follow a Fordist paradigm, meaning 
that the BPMS forces process participants to act in a certain direction, i.e. exactly 
in the way it is captured in a process model. In the context of processes where 
unanticipated exceptions are common and where there is no predictable way to per- 
form the process, a BPMS often ends up obstructing the work of process partici- 
pants rather than supporting them. Approaches to support non-standardized or un- 
predictable processes are described by Reichert et al. [69]. One of those approaches 
is case handling as discussed in the Box “Types of BPMS”. An introduction to this 
topic is given by Van der Aalst et al. [96], while a more comprehensive treatment of 
the subject is provided by Swenson [91]. 
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A discussion on executable BPMN 2.0 is provided in Silver’s book [87], as well 
as in the book by Freund and Riicker [19]. An in-depth coverage of process automa- 
tion using the YAWL language is given by ter Hofstede et al. [92]. 

A gentle introduction to XML, XML Schema and XPath can be found in Mgller 
and Schwartzbach’s book [56]. Meanwhile, the topic of Web services is covered 
in-depth by Erl et al. [17]. The latter book also includes a discussion on WSDL 
2.0—the default technology for implementing service interfaces in BPMN 2.0. 


Chapter 10 
Process Intelligence 


If you can’t measure something, you can’t understand it. If you 
can’t understand it, you can’t control it. If you can’t control it, 
you can’t improve it. 

H. James Harrington (1929-) 


It is a central idea of BPM that processes are explicitly defined, then executed, and 
that information about process execution is prepared and analyzed. In this way, this 
information provides a feedback loop on how the process might be redesigned. Data 
about the execution of processes can stem from BPMSs in which processes are 
specified, but also from systems that do not work with an explicit process model, 
for instance ERP systems or ticketing systems. Data from those systems have to be 
transformed to meet the requirements of intelligent process execution analysis. This 
field is typically referred to as process mining. 

This chapter deals with intelligently using the data generated from the execu- 
tion of the process. We refer to such data as event logs, covering what has been 
done when by whom in relation to which process instance. First, we investigate the 
structure of event logs, their relationship to process models, and their usefulness for 
process monitoring and controlling. Afterwards, we discuss three major objectives 
of intelligent process analysis, namely transparency, performance and conformance. 
We discuss automatic process discovery as a technical step to achieve transparency 
of how the process is executed in reality. Then, we study how the analysis of event 
logs can provide insights into process performance. Finally, we discuss how the 
conformance between event logs and a process model can be checked. 


10.1 Process Execution and Event Logs 


In the previous chapter, we studied how a process model can be specified in a way 
that a BPMS can support its execution. Both process participants and process own- 
ers are involved in the execution of business processes. However, their perspective 
is quite different. Process participants work on tasks, which produce execution data 
as a side product. We call this data event logs. Process owners are particularly inter- 
ested in drawing conclusions from such event logs. In this section, we discuss which 
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questions can be answered using event data and how event logs and process models 
relate to each other. 


10.1.1 The Perspective of Participants on Process Execution 


When a process is executed on a BPMS or another piece of software, there is a 
clear separation between coordination and execution of tasks. The system usually 
takes care of coordinating individual cases informing participants about which tasks 
they need to work on. Accordingly, participants often see only those tasks that they 
are directly responsible for, while the system hides the complexity of the overall 
process. Each participant typically has a personal worklist that shows the set of 
work items that still need to be worked on. If an explicit process model exists, each 
of these work items corresponds to a task in the process model. However, there 
might exist multiple work items corresponding to a single task if several cases are 
currently being worked on. For example, at a specific point in time, Chuck as a 
process participant might see that four work items are in his worklist, all relating to 
the “Confirm order” task of the order fulfillment process: one work item relates to 
an order from customer A, one from customer B, and two from customer C. 

The structure of a work item is defined in the executable process model or directly 
implemented in the software. This means that participants see those data fields that 
have been declared as input for a task. For each work item they are working on, they 
are supposed to document at least the completion. In this way, the system can keep 
track of the state of the process at any point in time. Among others, it is easy to 
record at which point in time somebody has started working on a work item, which 
input data were available, what output data were created, and who was the partici- 
pant working on it. For example, when Chuck has confirmed the order of customer 
B, he enters the result in the system, and the system can decide automatically if next 
the invoice should be emitted or the order confirmation should be escalated to some- 
one above Chuck. Most BPMSs and also other information systems record such data 
on what has been done at which point in time. The file in which these data is stored 
is called a log file, and the data in it is called event logs. Each time another task is 
completed, a new entry is added to the log file. That is, once Chuck has entered his 
data, the system appends a line in the log file stating that Chuck has confirmed an 
order with a corresponding timestamp. 


10.1.2 The Perspective of the Process Owner on Process Execution 


Event logs have the potential to reveal important management insights into how 
a process works in reality. Therefore, the process owner is most interested in an- 
alyzing it in a systematic way. In essence, we distinguish three major application 
scenarios for using event logs: automatic process discovery, performance analysis 
and conformance checking, all related to questions the process owner might ask. 
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What is the actual process model? Automatic process discovery is concerned 
with the question of how a process actually works in reality. In Chap. 5, we 
mentioned that the event logs can be used as an input to evidence-based process 
discovery. Automatic process discovery utilizes event logs for the generation of 
a corresponding process model. In this way, event logs are valuable to find a 
process model where no model existed before, and to adjust an existing model 
according to how the process really works. 

What is the performance of the process? In Chap. 7, we discussed that process 
analyses such as flow analysis suffer from the fact that the average cycle time 
for each task in the process model needs to be estimated. Also, often strong 
assumptions are required such that the behavior of the process is not influenced 
by the load. Using event logs, we are able to inspect the actual behavior of a 
process and compare it with insights from process analysis. Furthermore, historic 
information about process execution can be leveraged for making operational 
decisions. 

To which extent are the rules of the process model followed? Conformance 
checking is a collection of techniques that compare a set of event logs with a set 
of constraints or an existing process model. There are situations when process 
models are defined, but they are not strictly enforced by a corresponding BPMS. 
In these situations, conformance checking can be utilized in order to determine 
how often the process is executed as expected and, if not, at which stages devi- 
ations can be found. Here, event logs help to understand either where the model 
needs to be corrected or where the behavior of the participants working in the 
process has to be adapted. 


By providing answers to these three types of question, we can get insights into 
the process, which may help to reposition it in the Devil’s Quadrangle. Specifically, 
the dimension of time increases in transparency by investigating event logs: the 
timestamps show when tasks are executed and how long they take. There is also a 
strong association with cost if the working time of the participants working in the 
process can be assigned to a particular process instance. Flexibility can be analyzed 
based on the different paths a process takes. The historic set of actually used paths 
and their variety gives an indication for this dimension. Finally, also quality issues 
might be identified from event logs, for instance when inspecting the number of 
reworks and iterations required for a specific task. 

The process owner can use event logs as input to two different control mecha- 
nisms: on an aggregated level and on an instance level. The mechanisms are called 
process controlling and process monitoring, respectively. 


Process Controlling deals with the analysis of historic process execution. The in- 
put for process controlling are event logs that relate to a particular period of time, 
for instance a quarter or a full year. Process controlling provides insights into 
whether the general objectives of a process have been met and whether the KPIs 
are in line. Typically, process controlling is an offline activity, which involves 
logs of completed process executions. 
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Process Monitoring is concerned with the quality of currently running process in- 
stances. The input for process monitoring are the event logs of individual process 
instances or cases. Process monitoring works with objectives and rules that are 
formulated for these individual cases, and triggers counteractions when these 
rules are violated, for instance when a customer request is not responded in 
time. Typically, process monitoring is a continuous online activity which involves 
events of currently running instances. 


Both process monitoring and process controlling play an important role in align- 
ing the process with its overall business objectives. In that respect, they are closely 
related to ideas of quality management and the Plan-do-check-act (PDCA) cycle. 
PDCA can be regarded as an inspiration for the concept of a business process man- 
agement lifecycle as discussed in the first chapter of this book. Process monitoring 
and controlling (check) investigate the data from executing processes (do) such that 
redesign measures (act) can be taken to realign the execution with the objectives 
(plan). All these concepts have inspired the idea of a process cockpit as a software 
tool where data on the execution of processes is provided online using charts and 
appropriate visualization (see Fig. 9.4 for an example). Often, these tools are also 
called Business Activity Monitoring (BAM) tools or Process Performance Measure- 
ment (PPM) tools. 


10.1.3 Structure of Event Logs 


Process monitoring and controlling strongly rely on event data to be recorded during 
the execution of processes. Event logs contain a set of events. Accordingly, we can 
understand an event log as a list of event recordings. Figure 10.1 gives an illustration 
of what data is typically stored in event logs. We can see that a single event has a 
unique event ID. Furthermore, it refers to one individual case, it has a timestamp, 
and it shows which resources executed which task. These may be participants (e.g. 
Chuck and Susi) or software systems (SYS1, SYS2, DMS). For several analysis 
techniques that we will discuss in this chapter, it is a minimum requirement that the 
events in the log refer to (i) one case, (ii) one task, and (iii) a point in time. Having 
these three pieces of information available, we can for instance discover a process 
model from the logs. In practice, there are often additional pieces of information 
stored for each event like costs, system being used, or data on the handled business 
case. These can be used for clustering, correlating or finding causal relationships in 
the event logs. 

The event log of Fig. 10.1 is captured as a list in a tabular format.' The problem 
with event logs is that each vendor and software system defines individual log for- 
mats. In order to leverage the adoption of event log analysis tools such as the open 


'For simplicity, we only consider one supplier in this example. 
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Case ID Event ID 
Ch-4680555556-1 
Re-5972222222-1 
Co-6319444444-1 
Ge-6402777778-1 
Em-6555555556-1 
Re-4180555556-1 
Sh-4659722222-1 
Ar-3833333333-1 
Ch-4055555556-2 
Ch-4208333333-2 
Re-4666666667-2 
Ob-3263888889-2 
Ma-6131944444-2 
Co-6187615741-2 
Em-6388888889-2 
Ge-64398148 
Sh-727777777 
Re-36111111 


Sh-70138888 
Ge-706944444 
Re-4305555556-3 
Ar-4340277778-3 
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Timestamp 

2012-07-30 11:14 
2012-07-30 14:20 
2012-07-30 15:10 
2012-07-30 15:22 
2012-07-30 15:44 
2012-08-04 10:02 
2012-08-05 11:11 
2012-08-06 09:12 
2012-08-01 09:44 
2012-08-01 10:06 
2012-08-01 11:12 
2012-08-03 07:50 
2012-08-04 14:43 
2012-08-04 14:51 
2012-08-04 15:20 
2012-08-04 15:27 
2012-08-04 17:28 
2012-08-07 08:40 
2012-08-07 08:50 
2012-08-02 10:06 
2012-08-02 10:11 
2012-08-02 16:04 
2012-08-02 16:12 
2012-08-02 16:33 
2012-08-02 16:50 
2012-08-02 16:58 
2012-08-06 10:20 
2012-08-06 10:25 
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Activity Resource 
Check stock availability 
Retrieve product from warehouse 
Confirm order 

Get shipping address 

Emit invoice 

Receive payment 

Ship product 

Archive order 

Check stock availability 
Check materials availability 
Request raw materials 
Obtain raw materials 
Manufacture product 
Confirm order 

Emit invoice 

Get shipping address 

Ship product 

Receive payment 

Archive order 

Check stock availability 
Check materials availability 
Manufacture product 
Confirm order 

Emit invoice 

Get shipping address 

Ship product 

Receive payment 

Archive order 


Ch-3409722222-4 
Re-5000115741-4 
Co-5041898148-4 
Ge-5223148148-4 
Em-4034837963-4 
Re-4180555556-4 
Sh-5715277778-4 
Ar-5888888889-4 


1 
1 
1 
1 
1 
1 
a: 
1 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
3 
3 
3 
3 
3 
3 
3 
3 
3 
4 
4 
4 
4 
4 
4 
4 
4 


2012-08-04 08:11 
2012-08-04 12:00 
2012-08-04 12:06 
2012-08-04 12:32 
2012-08-08 09:41 
2012-08-08 10:02 
2012-08-08 13:43 
2012-08-08 14:08 


Check stock availability 

Retrieve product from warehouse 
Confirm order 

Get shipping address 

Emit invoice 

Receive payment 

Ship product 

Archive order 


Fig. 10.1 Example of an event log for the order fulfillment process 


source tool ProM,” the IEEE Task Force on Process Mining promotes the usage of 
the eXtensible Event Stream (XES) format. Several tools work with XES event logs 
or offer features to convert events logs into this format. The metamodel of XES is 
illustrated in Fig. 10.2. Each XES file represents a log. It contains multiple traces, 
and each trace can contain multiple events. All of them can contain different at- 
tributes. An attribute has to be either a string, date, int, float, or boolean element as 
a key-value pair. Attributes have to refer to a global definition. There are two global 
elements in the XES file, one for defining trace attributes, the other for defining 
event attributes. Several classifiers can be defined in XES. A classifier maps one of 
more attributes of an event to a label that is used in the output of the analysis tool. 
In this way, for instance, events can be associated with activities. 


>The software is available at http://www.promtools.org. 
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Fig. 10.2 Metamodel of the 
XES format 
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Fig. 10.3 Example of a file <log xes.version="1.0" xes.features="arbitrary-depth" xmIns="http://.../xes"> 
in the XES format <extension name="Concept” prefix="concept” uri="http://.../xes/concept.xesext”/> 


<extension name="Time” prefix=”time” uri="http://.../xes/time.xesext”/> 
<global scope="trace”> 
<string key="concept:name” value=""/> 
</global> 
<global scope="event”> 
<string key="concept:name” value=""/> 
<date key="time:timestamp” value=”1970-01-01T00:00:00.000+00:00”/> 
<string key="resource” value=""/> 
</global> 
<classifier name="Activity” keys=”concept:name”/> 
<float key="log attribute” value=”2335.23”/> 
<trace> 
<string key="concept:name” value="1"/> 
<event> 
<string key="concept:name” value="Check stock availability”/> 
<date key="time:timestamp” value=”2012-07-30T11:14:00:000+01:00"/> 
<string key=”resource” value="Chuck”/> 
</event> 
<event> 
<string key="concept:name” value=”Retrieve product from warehouse”/> 
<date key="time:timestamp” value=”2012-07-30T14:20:00:000+01:00"/> 
<string key="resource” value="Rick”/> 
</event> 
</trace> 
</log> 


Figure 10.3 shows how parts of the information of the event log example from 
Fig. 10.1 can be stored in an XES file. From the first “global” element (scope = 
“trace’”), we see that each trace element is expected to have a “concept:name’” at- 
tribute. For the trace defined below, this attribute has the value 1. Furthermore, there 
are three different attributes expected for an event (“global” element with scope = 
“event’): “concept:name’’,, “time:timestamp”, and “resource”. In the trace defined 
below, we observe two events. The first one refers to “Check stock availability”, 
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which was completed by SYS1 on the 30th of July 2012 at 11:14. The second event 
captures “Retrieve product from warehouse” conducted by Rick at 14:20. 


10.1.4 Challenges of Extracting Event Logs 


Event data that is available in some tabular format like that visualized in Fig. 10.1 
can be readily converted to XES, and then analyzed using appropriate tools. In many 
cases though, the data which is relevant for event logs is not directly accessible in the 
required format, but has to be extracted from different sources and to be integrated. 
Therefore, we can identify five major challenges for log data extraction, potentially 
requiring considerable effort in a project. These challenges are: 


1. Correlation challenge: This refers to the problem of identifying the case an 
event belongs to. Many information systems do not have an explicit notion of 
process defined. Therefore, we have to investigate which attribute of process- 
related entities might serve as a case identifier. Often, it is possible to utilize 
entity identifiers such as order number, invoice number, or shipment number. 

2. Timestamps challenge: The challenge to work properly with timestamps stems 
from the fact that many information systems do not consider logging as a primary 
task. This means that logging is often delayed until the system has idle time or 
little load. Therefore, we might find sequential events with the same timestamp in 
the log. This problem is worsened when logs from different information systems 
potentially operating in different time zones have to be integrated. Partially, such 
problems can be resolved with domain knowledge, for example when events are 
known to always occur in a specific order. 

3. Snapshots challenge: This point refers to the issue of having log data available 
for a certain period of time. For long running processes, we might not be able to 
observe all cases of the log with their full end-to-end duration in the considered 
period of time. It is a good idea to exclude such incomplete cases with missing 
head or tail. However, one should be aware that such a filtering might also intro- 
duce a bias, for instance that only brief cases are considered. Therefore, the time 
span reflected by the log should be significantly longer than the average duration 
of a case. 

4. Scoping challenge: The scoping of the event spectrum is a challenge when the 
available information system does not directly produce event logs. Information 
systems such as ERP systems record an extensive amount of process-related 
events in numerous tables. Event logs have to be generated from the entries in 
these tables, which requires a detailed understanding of the data semantics. Such 
system expertise may not readily be available. 

5. Granularity challenge: Typically, we are interested in conducting event log 
analysis on a conceptual level for which we have process models defined. In 
general, the granularity of event log recording is much finer such that each ac- 
tivity of a process model might map to a set of events. For example, an activity 
like “Retrieve product from warehouse” on the abstraction level of a process 
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model maps to a series of events like “Work item #1,211 assigned”, “Work item 
#1,211 started’, “Purchase order form opened”, “Product retrieved” and “Work 
item #1,211 completed”. Often, fine-granular events may show up repeatedly in 
the logs while on an abstract level only a single task is executed. Therefore, it is 
difficult to define a precise mapping between the two levels of abstraction. 


Exercise 10.1 Consider the final assembly process of Airbus for their A380 series. 
The final assembly of this aircraft series is located at the production site in Toulouse, 
France. Large parts are brought by ship to Bordeaux and brought to Toulouse by 
waterway and road transport. What is the challenge when log data of the A380 
production process has to be integrated? 


10.2 Automatic Process Discovery 


Automatic process discovery is a specific process mining technique. The goal of au- 
tomatic process discovery is to construct a process model that captures the behavior 
of an event log in a representative way. The construction is meant to work automat- 
ically and generically, using an algorithm that should make minimal assumptions 
about properties of the log and the resulting process model. Being representative 
in this context loosely means that the constructed process model should be able to 
replay the cases of the event log and forbid behavior not found in the logs. In the 
following, we first discuss log data assumptions, then we present the a-algorithm 
as a basic discovery algorithm, and turn to the notion of representativeness in more 
detail. 


10.2.1 Assumptions of the a-Algorithm 


The a-algorithm is a basic algorithm for discovering process models from event 
logs. It is basic as it is less complex than other, more advanced algorithms. Beyond 
that, it makes certain assumptions about the provided event logs that we will later 
discuss as partially being problematic. These assumptions are the following: 


e Order of Events: The events in the log are chronologically ordered. Such a 
chronological order can be defined based on timestamps. 

Case Reference: Each event refers to a single case. 

Activity Reference: Each event relates to a specific activity of the process. 
Activity Completeness: Each activity of the process is included in the log. 
Behavioral Completeness: The log is behaviorally complete in the sense that if 
an activity a can be directly followed by an activity b, then there is at least one 
case in the log where we observe ab. 
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Case ID Event ID Timestamp 


Activity 


Ch-468 2012-07-30 11:14 
Re-597 2012-07-30 14:20 
Co-631 2012-07-30 15:10 
Ge-640 2012-07-30 15:22 
Em-655 2012-07-30 15:44 
Re-418 2012-08-04 10:02 
Sh-465 2012-08-05 11:11 
Ar-383 2012-08-06 09:12 
Ch-405 2012-08-01 09:44 
Ch-420 2012-08-01 10:06 
Re-466 2012-08-01 11:12 
Ob-326 2012-08-03 07:50 
Ma-613 2012-08-04 14:43 
Co-618 2012-08-04 14:51 
Em-638 2012-08-04 15:20 
Ge-643 2012-08-04 15:27 
Sh-727 2012-08-04 17:28 
Re-361 2012-08-07 08:40 
Ar-368 2012-08-07 08:50 


1 
1 
1 
1 
1 
1 
1 
1 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
2 


Check stock availability 

Retrieve product from warehouse 
Confirm order 

Get shipping address 

Emit invoice 

Receive payment 

Ship product 

Archive order 


Check stock availability 
Check materials availability 
Request raw materials 
Obtain raw materials 
Manufacture product 
Confirm order 

Emit invoice 

Get shipping address 
Ship product 

Receive payment 
Archive order 


Fig. 10.4 Definition of a workflow log 
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Check stock availability 

Retrieve product from warehouse 

Check materials availability 

Request raw materials 

Obtain raw materials 

Manufacture product 

Confirm order 

Get shipping address 

Ship product 

Emit invoice 

Receive payment 

Archive order 
Workflow Log 
a,b,g,h,j,k,i,| 
a,c,d,e,f,g,j,h,i,k,| 


The first three assumptions refer to the information content of an event in the 
logs. These assumptions are rather general and non-restrictive. The activity com- 
pleteness criterion refers to the fact that we can only include those activities in the 
generated process model that we observe in the logs. The behavioral completeness 
has the strongest implications. In practice, we can hardly assume that we find the 
complete set of behavioral options in a log. Advanced techniques try to make weaker 
assumptions on this point. 

In line with these assumptions, we use a so-called workflow log as starting point 
for using the w-algorithm. Figure 10.4 shows how a workflow log can be constructed 
from an event log. In the following, we will work with letters as a reference to tasks. 
A workflow log is a collection of all unique execution sequences observed in the 
log. The aw-algorithm does not distinguish how often a specific execution sequence 
was observed in a workflow log. 


Exercise 10.2 Have a look at Fig. 10.1 and translate it into a workflow log following 
the same mapping rules as in Fig. 10.4. 


10.2.2 The Order Relations of the «-Algorithm 


The a-algorithm works in two phases in order to construct a process model. In the 
first phase, different order relations are extracted from the workflow log L. In the 
second phase, the process model is constructed in a stepwise fashion from these 
identified relations. The order relations refer to tasks which directly follow one an- 
other in the log. It provides the basis for the definition of three more specific rela- 
tions that refer to causality, to potential parallelism and to non-succession. We refer 
to this set of relations as the @ relations. 
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Fig. 10.5 Simple control (a) 
flow patterns a; OF 
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e The basic order relation a > b holds if we can observe in the workflow log L that 
an task a is directly followed by b. 

e The causality relation a — b is derived from the basic relation. It holds if we 

observe in L that a > b and that b ¥ a. 

The relation of potential parallelism a || b holds if both a > b and b > a is ob- 

served in the workflow log L. 

The relation of no direct succession a#b holds if a 4 b and b # a. 


The reason why exactly these relations are used is shown in Fig. 10.5. There are 
five characteristic combinations of relations between the tasks in a workflow log that 
can be mapped to simple control flow patterns. 


Pattern (a) depicts a sequence of tasks a and b. If we model them in this way, 
it should be guaranteed that in a workflow log we will find a followed by b, 
i.e. a > b, but never b followed by a, i.e. b 4 a. This means that the causality 
relation a — b should hold. 

Pattern (b) also relates to a characteristic combination of relations. The workflow 
log should show that a > b and a —> c hold, and that b and c would not be 
mutual successors, i.e. bic. 

Pattern (c) also requires that b and c would not be mutual successors, i.e. bic, 
while both b > d and c > d have to hold. 

Pattern (d) demands that a — b and a > c hold, and that b and c show potential 
parallelism, i.e. b || c. 

Pattern (e) refers to b > d and c > d while Db and c show potential parallelism, 
ie. b || c. 


The idea of the q-algorithm is to identify the relations between all pairs of 
tasks from the workflow log in order to reconstruct a process model based on 
Patterns (a) to (e). Therefore, before applying the a-algorithm, we first have to 
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Fig. 10.6 Footprint 
represented as a matrix of the 
workflow log 
L=[(a,b,g,h, j,k,i,l), 

(a,c, d,e, f,g, j,h,i,k,l)) 


extract all basic order relations from the workflow log L. Consider the work- 
flow log depicted in Fig. 10.4 containing the two cases (a,b, g,h, j,k,i,1) and 
(a,c,d,e, f,g, j,h,i, k,l). From this workflow log, we can derive the following 
relations. 


e The basic order relations > refer to each pair of tasks that directly follow one 
another. It can be directly read from the log: 


a>b|h>j|i>l|d>e|g>j|i>k 


b>gl]|j>k\)a>c\le>f|j>h|k>l 


g>h|k>i|lc>d|f>g|h>i 


e The causal relations can be found when we check of each order relation whether 
it does not holds in the opposite direction. This holds for all pairs except (A, j) 
and (i, k), respectively. We get: 


a>b|\|j>k|a>c|d->e|frog {hoi 


bog |ivol |cod\leof|groj)]kol 


g—oh 


e The potential parallelism relation holds true for h || j as well as for k || i (and the 
corresponding symmetric cases). 

e The remaining relation of no direction succession can be found for all pairs that 
do not belong to — and |]. It can be easily derived when we write down the 
relations in a matrix as shown in Fig. 10.6. This matrix is also referred to as the 
footprint matrix of the log. 


Exercise 10.3 Have a look at the workflow log you constructed in Exercise 10.2. 
Define the relations >, —, ||, # and the footprint matrix of this workflow log. 
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10.2.3: The a-Algorithm 


The a-algorithm is a basic algorithm for automatic process discovery that takes an 
event log L and its q@ relations as a starting point. The essential idea of the algorithm 
is that tasks that directly follow one another in the log should be directly connected 
in the process model. Furthermore, if there is more than one task that can follow 
after another, we have to determine whether the set of succeeding tasks is partially 
exclusive or concurrent. An exception from the principle that tasks should be con- 
nected in the process model are those that are potentially parallel, i.e. those pairs 
included in ||. The details of the w-algorithm are defined according to the following 
eight steps.° 


1. Identify the set of all tasks in the log as Ty. 
2. Identify the set of all tasks that have been observed as the first task in some case 

as T]. 

3. Identify the set of all tasks that have been observed as the last task in some case 
as To. 
4. Identify the set of all connections to be potentially represented in the process 

model as a set X;,. Add the following elements to X_;: 

a. Pattern (a): all pairs for which hold a —> b. 

b. Pattern (b): all triples for which hold a — (bic). 

c. Pattern (c): all triples for which hold (b#c) > d. 

Note that triples for which Pattern (d) a > (b || c) or Pattern (e) (b || c) > d 

hold are not included in X;. 

5. Construct the set Y;, as a subset of Xz, by: 
a. Eliminating a > b and a — c if there exists some a > (bic). 
b. Eliminating b > c and b — d if there exists some (bic) > d. 
6. Connect start and end events in the following way: 

a. If there are multiple tasks in the set 7; of first tasks, then draw a start event 
leading to a split (XOR or AND depending on the relation between the tasks), 
which connects to every task in 77. Otherwise, directly connect the start event 
with the only first task. 

b. For each task in the set To of last tasks, add an end event and draw an arc 
from the task to the end event. 

7. Construct the flow arcs in the following way: 

a. Pattern (a): For each a > b in Y_, draw an arc a to b. 

b. Pattern (b): For each a — (bic) in Y;,, draw an arc from a to an XOR-split, 
and from there to b and c. 

c. Pattern (c): For each (b#c) — d in Y_, draw an arc from b and c to an XOR- 
join, and from there to d. 


3Note that the a-algorithm was originally defined for constructing Petri nets. The version shown 
here is a simplification based on the five simple control flow patterns of Fig. 10.5 in order to 
construct BPMN models. 
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Fig. 10.7 Process model constructed by the a-algorithm from workflow log L = [(a, b, g,h, j, 
k,i,1), (a,c, d,e, f, g, j,h,i, k,1)] 


d. Pattern (d) and (e): If a task in the so constructed process model has multiple 
incoming or multiple outgoing arcs, bundle these arcs with an AND-split or 
AND-join, respectively. 

8. Return the newly constructed process model. 


Let us step through the a-algorithm with the workflow log L = [(a, b, g,h, j, 
k,i,l), (a,c, d,e, f,g, j,h,i,k,l)] as an example input. The Steps 1-3 identify 
T, = {a,b,c,d,e, f,g,h,i, j,k, 1}, Ty = {a}, and To = {I}. In Step 4a all causal 
relations are added to X_;, including a > b anda — c, etc. In Step 4b, we work row 
by row through the footprint matrix of Fig. 10.6 and check if there are cells sharing 
a — relation while relating to tasks that are pairwise in #. In the row a, we observe 
both a > b and a > c. Also, b#c holds. Therefore, we add a — (b#c) to X,. We 
also consider row g and its relation to h and j. However, as h || j holds, we do not 
add them. In Step 4c, we progress column by column through the footprint matrix 
and see if there are cells sharing a > relation while relating to tasks that are mutu- 
ally in #. In column g, we observe two — relations to b and f. Also, b#f holds. 
Accordingly, we add (b# f) — g to X,. We also check i and k that share the same 
relation to 1. However, as i || k holds, we do not add them. There are no further 
complex combinations found in Step 4d. 

In Step 5, we eliminate the basic elements in X;, that are covered by the complex 
patterns found in Steps 4b and 4c. Accordingly, we delete a ~ b,a > c, b— g, 
and f — g. In Step 6a we introduce a start event and connect it with a; in 6b, 
task / is connected with an end event. In Step 7, arcs and gateways are added for 
the elements of Y;. Finally, in Step 8 the process model is returned. The resulting 
model is shown in Fig. 10.7. 
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Fig. 10.8 Examples of two short loops, which are problematic for the w-algorithm 
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Exercise 10.4 Have a look at workflow log and the footprint you constructed in 
Exercises 10.2 and 10.3. Document progressing through the steps of the w-algorithm 
with this input and draw the resulting process model. 


10.2.4 Robust Process Discovery 


Clearly, the a-algorithm has its merits. It can reconstruct a process model from a 
behaviorally complete event log if that log has been generated from a structured 
process model. There are also limitations to be noted, though. The a-algorithm is 
not able to distinguish so-called short loops from true parallelism. As can be seen 
in Fig. 10.8, all three models can produce the workflow logs that yield b || c in the 
corresponding footprint. Several extensions to the w-algorithm have been proposed. 
The idea of the a+-algorithm is to define the relation || in a stricter way such that 
b || c is only included if there is no sequence bcb in the logs. In this way, models 
(a) and (b) in Fig. 10.8 can be distinguished from each other in their generated logs. 
Furthermore, we can use preprocessing to extract direct repetition like aa or bb 
from the logs, note down the corresponding tasks, and continue with a log from 
which such repeated behavior is mapped to a single execution. 

Further problems for the a-algorithm are incompleteness and noise. The notion 
of completeness assumed by the a-algorithm relates to the > relation from which 
the other relations are derived. The number of required different cases increases with 
the factorial of the number of potentially concurrent tasks. Often, this number is low. 
But already for 10 concurrent tasks, we require 10! = 3, 628, 800 cases. Therefore, 
it is desirable to use algorithms that can explicitly distinguish likely and unlikely 
behavior in order to generalize when logs are not complete. This direction also helps 
in addressing problems with noise. Event logs often include cases with a missing 
head, a missing tail, or a missing intermediate episode. Furthermore, there may be 
logging errors with events being swapped or recorded twice. Such unlikely behavior 
should not distort the process discovery result. 

Several approaches have been defined for addressing problems of completeness 
and noise. In general, they try to balance four essential quality criteria, namely fit- 
ness, simplicity, precision, and generalization. Fitness refers to the degree of log be- 
havior that a process model is able to replay. It can be defined based on the fraction 
of event patterns represented by the model or based on the fraction of cases that can 
be replayed in the model. Simplicity means that the resulting process model should 
be readily understandable. It can be measured using different complexity metrics 
for process models such as model size or degree of structuredness. Precision refers 
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to the degree of behavior that is allowed by the model, but not observed in the logs. 
We can easily create a process model that allows the execution of all tasks in any 
arbitrary order with potential repetition. However, we can hardly learn any specifics 
of the process from such a model. Generalization refers to the ability of a process 
model to abstract from the behavior that is documented in the logs. A discovery 
technique that is able to generalize helps to work with incomplete behavior. 


Exercise 10.5 Draw a model in BPMN with which you can replay any execution 
sequence that includes tasks a, b, c, d, e. Furthermore, discuss the fitness, simplicity, 
precision, and generalization of such a model for the trace (a,b,c, d,e). 


10.3 Performance Analysis 


In Sect. 7.1 we introduced the four performance dimensions of time, cost, quality 
and flexibility. In turn, Chap. 8 demonstrated that these four dimensions form a 
Devil’s Quadrangle when we try to improve a process. These performance measures 
are usually considered to be generally relevant for any kind of business. Beyond this 
general set, a company should also identify specific measures. Often, the measures 
are industry-specific, like profit per square-meter in gastronomy, return rate in online 
shopping or customer churn in marketing. Any specific measure that a company 
aims to define should be accurate, cost-effective and easy-to-understand. Here, we 
focus on the four general performance measures of time, cost, quality and flexibility. 
The question of this section is how we can spot that a process does not perform well 
according to one of these dimensions. Event logs provide us with very detailed data 
that is relevant to performance. We will describe techniques that help us to measure 
and to visualize potential performance problems that relate to time, cost, quality and 
flexibility. 


10.3.1 Time Measurement 


Time and its more specific measures cycle time and waiting time are important gen- 
eral performance measures. Event logs typically show timestamps such that they can 
be used for time analysis. Time analysis is concerned with the temporal occurrence 
and probabilities of different types of event. The event logs of a process generally 
relate each event to the point in time of its occurrence. Therefore, it is straight- 
forward to plot events on the time axis. Furthermore, we can utilize classifiers to 
group events on a second axis. A classifier typically refers to one of the attributes 
of an event, like case ID or participant ID. There are two levels of detail for plotting 
events in a diagram: dotted charts using the timestamp to plot an event, and timeline 
chart showing the duration of a task and its waiting time. 

The dotted chart is a simple, yet powerful visualization tool for event logs. Each 
event is plotted on a two-dimensional canvas with the first axis representing its 
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Fig. 10.9 Dotted chart of log data 


occurrence in time and the second axis as its association with a classifier like a case 
ID. There are different options to organize the first axis. Time can be represented 
either relative such that the first event is counted as zero, or absolute such that later 
cases with a later start event are further right in comparison to cases that started 
earlier. The second axis can be sorted according to different criteria. For instance, 
cases can be shown according to their historical order or their overall cycle time. 
Figure 10.9 shows the dotted chart of the logs of a healthcare process. The events 
are plotted according to their relative time and sorted according to their overall cycle 
time. It can be seen that there is a considerable variation in terms of cycle time. 
Furthermore, the chart suggests that there might be three distinct classes of cases: 
those that take no more than 60 days, those taking 60 to 210 days, and a small class 
of cases taking longer than 210 days. Such an explorative inspection can provide a 
good basis for a more detailed analysis of the factors influencing the cycle time. 


Exercise 10.6 Draw a dotted chart of the event log in Fig. 10.1 showing relative 
cycle time and being sorted by cycle time. 


The temporal analysis of event logs can be enhanced with further details if a 
corresponding process model is available and tasks can be related to a start and to 
an end event. The idea is to utilize the concept of token replay for identifying the 
point in time when a task gets activated. For tasks in a sequence, the activation time 
is the point in time when the previous task completed. For tasks after an AND-join, 
this is the point in time when all previous tasks have completed. For XOR-joins and 
splits it is the point when one of the previous tasks completes. 

Using this information, we can plot a task not as a dot but as a bar in a timeline 
chart (see Fig. 10.10). A timeline chart shows a waiting time (from activation until 
starting) and a processing time (from starting until completion) for each task. The 
timelines of each task can be visualized in a similar way as a dot in the dotted 
chart. The timeline chart is more informative than the dotted chart since it shows 
the duration of the tasks. Furthermore, it is helpful to see the waiting times. Both 


10.3. Performance Analysis 369 


HREM Processing time 
[HE Waiting time 


Fig. 10.10 Timeline chart of log data like PM 232 


pieces of information are a valuable input for quantitative process analysis. When 
thousands of cases are available as a log, one can estimate the distribution of waiting 
time and processing time of each task. In this way, bottlenecks with long waiting 
times can be spotted and, similarly, tasks that are most promising to focus redesign 
efforts upon. Furthermore, this information can also be used for predicting execution 
times of running process instances, which is helpful for process monitoring. 


Exercise 10.7 Calculate the waiting times required by a timeline chart for the event 
log in Fig. 10.1 using the process model of Fig. 10.7. 


10.3.2 Cost Measurement 


In a process context, cost measurement is mainly related to the problem of assigning 
indirect costs to cases. After all, direct costs like the purchasing costs of four wheels 
which are assembled on a car can be easily determined. Indirect labor or machine 
depreciation are more difficult. In accounting, the concept of Activity-based Costing 
(ABC) was developed to more accurately assign indirect costs to products and ser- 
vices, and to individual customers. The motivation of ABC is that human resources 
and machinery are often shared by different products and services, and they are used 
to serve different customers. For instance, the depot of BuildIT rents out expensive 
machinery such as bulldozers to different construction sites. On the one hand, that 
involves costs in terms of working hours of the persons working at the depot. On 
the other hand, machines like bulldozers lose in value over time and require main- 
tenance. The idea of ABC is to use activities for distributing the indirect costs, e.g. 
associated with the depot. 


Example 10.1 


According to Fig. 1.6 in Chap. 1, the rental process of BuildIT contains five major activities. 
We observe the following durations in the event logs for the case of a bulldozer rental 
requested on 21st August: 


e “Submit equipment rental request” is conducted by the site engineer. It takes the engineer 
20 minutes to fill in the form on paper. The production of each paper form costs €1. The 
site engineer gets an annual salary of €60,000. 

e The clerk receives the form and selects suitable equipment and checks the availability. 
Both activities together take 15 minutes. The clerk works at an annual rate of €40,000. 

e The works engineer reviews the rental request (annual salary of €50,000). This review 
takes 10 minutes. 
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e The clerk is also responsible for sending a confirmation including a purchase Order for 
renting the equipment, which takes 30 minutes. 


In order to work with these numbers we have to make certain assumptions. First, at BuildIT 
the actual working year contains 250 working days of 8 hours. Furthermore, all employees 
receive health insurance and pension contributions of 20 % on top of their salary. Finally, 
people are on average 10 days on a sick leave per year. Taking this into account, we can 
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engineer €0.63 per minute, for the clerk €0.42 per minute, and for the works engineer 
€0.52 per minute. Altogether, this case created costs of 20 minutes x €0.63 per minute + 
(15 + 30) minutes x €0.42 per minute + 10 minutes x €0.52 per minute, which sums up 
to €36.70. 

Now consider a case of a street construction process. We observe the following durations 
from the event logs for these two activities: 


calculate the labor cost of each participant per minute as 


e “Prepare the foundation” is conducted by four worker. It took one week at a specific 
construction case. The used excavator costs € 100,000. It is written off in five years and 
has annual maintenance costs of €5,000. A worker gets an annual salary of €35,000. 

e “Tar the road” is conducted by six workers. It took two days in this case. The tarring 
machine costs €200,000, is also written off in five years and costs € 10,000 annual main- 
tenance. 


For this case, we can also take the costs of the machinery into account. The labor cost per 
day is €175 for one worker. The excavator costs €20,000 + 5,000 per annum for write-off 
and maintenance, which is € 104.17 per working day. For the preparation of the foundation, 
this amounts to 4 x 5 x €175 +5 x €104.17 = €4,020.85. For the tarring of the road, 
the costs are 6 x 2 x €175 +2 x €208.34 = €2,516.68. 


Exercise 10.8 Consider that the paper form is printed by the site engineer in the 
rental process, that the printer costs €300 written off in three years, and that a pile 
of 500 pieces of paper costs € 10. Why could it make sense to include these costs in 
the calculation, why not? 


An inherent problem of ABC is the detail of data that is required for tracking the 
duration of activities like renting out equipment or approving rental requests. Event 
data stored in process-aware information systems can help to provide such data. 
Also, technologies like Radio-frequency identification (RFID), which helps to track 
physical objects based on little RFID chips attached to it, are promising to overcome 
the tracking problem of ABC. Some systems only keep track of activity completion. 
However, ABC also requires the start of activities to be kept. This can be achieved 
by tracking timestamps of the point in time when a resource starts working on a 
specific task. What is important to take into account here is the cost of achieving 
additional transparency. There is a trade-off, and once it becomes overly expensive 
to gain more transparency, it is good to not include those costs in the calculation. 


10.3.3, Quality Measurement 


The quality of a product created in a process is often not directly visible from execu- 
tion logs. However, a good indication is to check whether there are repetitions in the 
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execution logs, because they typically occur when a task has not been completed 
successfully. Repetitions can be found in sequences of task. In Chap. 7, we saw 
that the loop of a rework pattern increases the cycle time of a task to CT = —_ 
in comparison to T being the time to execute the task only once. The question 
is now how we can determine the repetition probability r from a series of event 
logs? 

The first part of the answer to this question can be given by reformulating the 
equation such that it is solved for r. By multiplication with 1 —r we get CT —r x 
CT = T. Subtraction of CT yields —r x CT = T — CT, which can be divided by 
—CT resulting in 

T 
r=l1-—. 
CT 
Both CT and T can now be determined using the data of the event logs. Consider 
the five cases in which we observe the following execution times for task a: 


5 minutes, 10 minutes. 

10 minutes. 

20 minutes, 6 minutes, 10 minutes. 
5 minutes. 

10 minutes, 10 minutes. 


Oi ae 


The cycle time CT of a can now be calculated as the average execution time of a 
per case, while the average execution time T is the average execution time of a per 
instantiation. Both can be determined based on the sum of all executions of a, which 
is 86 minutes here. We have five cases, such that CT = 86/5 = 17.2. Altogether, a 

86/9 __ 


is executed nine times yielding T = 86/9 = 9.56. Hence, we get r = 1 — 86/5 = 


1- 3 = 0.44. Of course, this calculation is only an approximation of the real value 
for r. It builds on the assumption that the duration of a task always follows the same 
distribution, no matter if it is the first, the second or another iteration. 


Exercise 10.9 Determine the probability of repetition r for the following execution 
times of task b: 


20 minutes, 10 minutes. 
30 minutes. 

30 minutes, 5 minutes. 
20 minutes. 

20 minutes, 5 minutes. 
25 minutes. 


ON Oe ee 


Also explain why the value is misleading for these logs. 


In some information systems it might be easier to track repetition based on the 
assignment of tasks to resources. One example are ticketing systems that record 
which resource is working on a case. Also, the logs of these systems offer insights 
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into repetition. A typical process supported with ticketing systems is incident res- 
olution. For example, an incident might be a call by a customer who complains 
that the online banking system does not work. Such an incident is recorded by a 
dedicated participant, e.g. a call center agent. Then, it is forwarded to a first-level 
support team who tries to solve the problem. In case the problem turns out to be too 
specific, it is forwarded to a second-level support team with specialized knowledge 
in the problem domain. In the best case, the problem is solved and the customer 
notified. In the undesirable case, the team identifies that the problem is within the 
competence area of another team. This has the consequence that the problem is 
rooted back to the first-level team. Similar to the repetition of tasks, we now see 
that there is a repeated assignment of the problem to the same team. According 
log information can be used to determine how likely it is that a problem is rooted 
back. 


10.3.4 Flexibility Measurement 


Flexibility refers to the degree of variation that a process permits. This flexibility 
can be discussed in relation to the event logs the process produces. For the company 
owning the process, this is important information in order to compare the desired 
level of flexibility with the actual flexibility. It might turn out that the process is 
more flexible than what is demanded from a business perspective. This is the case 
when flexibility can be equated with lack of standardization. Often, the performance 
of processes suffers when too many options are allowed. Consider again the process 
for renting equipment at BuildIT. The process requires an equipment rental request 
form to be sent by e-mail. Some engineers, however, prefer to call the depot directly 
instead of filling the form. Since these engineers are often highly distinguished, it is 
not easy for the clerk to turn down these calls. As a result, the clerk fills out the form 
while being on the phone. Not only does this procedure take more time, but also, 
due to noise at the construction site, it increases the likelihood of errors. In practice, 
this means that the rental process has two options to submit a request: by form (the 
standard procedure) and via the phone. 

Partially, such flexibility as described above can be directly observed in the event 
logs. We have seen that the workflow log of a process plays an important role for au- 
tomatic process discovery. It can also be used to assess the flexibility of the process. 
The workflow log summarizes the essential behavior of the process. As it defines 
each execution as a sequence of tasks, it abstracts from the temporal distance be- 
tween them. In this way, the workflow log contains a set of traces that have a unique 
sequence. This means that if two executions contain the same sequence of tasks, 
then they only result in a single trace to be included in the workflow log. This ab- 
straction of process executions in terms of a workflow log makes it a good starting 
point for discussing flexibility. Accordingly, the number of distinct executions DE 
can be defined based on a workflow log L as 


DE=|L|. 
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Exercise 10.10 Consider the event logs of the order fulfillment process in Fig. 10.1. 
What is the number of distinct executions DE? 


The question arises whether the number of distinct executions always gives a 
good indication for flexibility. At times, the number of distinct executions might give 
an overly high quantification of flexibility. This might be the case for processes with 
concurrency. Such processes can be highly structured, but having only a small set 
of concurrent tasks results in a rich set of potential execution sequences. Consider 
the process model constructed by the a-algorithm in Fig. 10.7. The tasks i and h are 
concurrent to j and k. Indeed, there are six options to execute them: 


i,h,j 
dik, i 
i, j,k 
j,i,A 
i, j,h 

k 


oJ 


Jot, 


ON vi Go hon 


While the order is not strict, all of them must be executed. Therefore, it might be 
a good idea to additionally consider whether a task is optional. If T refers to the 
number of tasks that appear in the workflow log, then the set Typ contains those 
tasks that are optional. Optionality according to the log means that for a particular 
task there exists at least one trace in which it does not occur. For the logs of Fig. 10.1, 
we observe that the tasks b to f depend upon the availability of raw materials. We 
can quantify the degree of optionality OPT as 
OPT = Pope. 

We can also approach the question of flexibility from the perspective of the au- 
tomatically discovered process model. This has some advantages since the degree 
of optionality does not reveal how many decisions have to be taken. If we consider 
the process model constructed by the w-algorithm in Fig. 10.7, we see that one deci- 
sion node is included (XOR-split). It distinguishes the situation whether the product 
is in stock or not. This observation can be quantified as the number of discovered 
decision points (DDP). For instance, the w-algorithm can be used to this end. 


10.4 Conformance Checking 


While performance analysis is concerned with measuring performance indicators, 
conformance checking is concerned with the question whether or not the execution 
of a process follows predefined rules or constraints. This question can be answered 
by inspecting the event logs. If a particular constraint does not hold, we speak of a 
violation. Conformance checking is concerned with identifying these violations and 
making statements about the extent of them altogether. This information provides 
important insights for the process owner. Apparently, when rules are not followed, 
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one should take corrective action. Violations might relate to one of the three process 
perspectives of control flow, data and resources in isolation or in combination. In 
the following, we describe how they can be specified. 


10.4.1 Conformance of Control Flow 


Conformance of control flow can be studied in two ways, either based on explicit 
constraints or based on a normative process model. Both can be related to each 
other, as many constraints can be automatically derived from a process model. First 
we will look into the approach assuming explicit constraints, after which we will 
discuss the use of a normative process model. 

We focus on three types of control-flow related constraint: mandatoriness, ex- 
clusiveness, and ordering. All these three constraint types define how two activities 
are allowed to be related in a process. A company might want to define that certain 
activities are mandatory because they are required from a control perspective. Con- 
sider again the case of BuildIT and the equipment rental process. A works engineer 
is supposed to review the rental request. This activity serves as a control for secur- 
ing that only appropriate equipment is rented. This measure might help to keep the 
rental costs in line. Such a control activity is a likely candidate for being a manda- 
tory activity. On the level of the logs, mandatory activity violations can be found 
by searching for traces in which they are left out. Exclusiveness might be specified 
for activities that relate to a decision. If, for instance, a rental request is rejected, 
BuildIT wants to make sure that there is no way to overwrite this decision. On the 
level of the log, this means that it shall never be possible that a rejection of a re- 
quest is followed by an approval. This exclusiveness can be checked by searching 
for traces in which both exclusive activities appear. The order of activities might be 
of specific importance to balance the performance of the process. In the equipment 
rental process, first the availability of the requested equipment is checked before the 
request is reviewed. This order constraint helps to relieve the workload of the works 
engineer who is supposed to review the request. Obviously, it is a waste of effort 
to review requests that cannot be met because the equipment is not available. Vio- 
lations to order constraints can be found by searching for traces with the activities 
appearing in the wrong order. 


Exercise 10.11 Consider the event logs of the order fulfillment process in Fig. 10.1. 
Which activities can be considered mandatory and exclusive to one another? 


Conformance of control flow can also be checked by comparing the behavior ob- 
served in the logs with a normative process model. The idea here is to replay each 
trace in the workflow log and to record at each step whether an activity was allowed 
to be executed according to the rules of the model. Typically, this requires the re- 
play of the logs in the process model. Based on the transition rules of BPMN, we 
can replay the case (a, b, g,i, j,k, 1) on the model shown in Fig. 10.11. In the initial 
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invoice payment 
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b) Retrieve 
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1) Archive 
order 


Fig. 10.11 BPMN model with token on start event for replaying the case (a, b, g, i, j, k,l) 


state, the process has a token on the start event. Once the case is started, this token 
moves to the output arc of the start event. This arc leads to activity a (“Check stock 
availability”), which means that the token enables this activity to be executed. The 
token moves to this activity while it is executed, and it is forwarded to the output 
arc once the activity is completed. Now, the XOR-split is activated, which means 
a decision has to be taken to either continue with b (“Retrieve product from ware- 
house”) or with f (“Manufacture product’). For the considered case, we continue 
with b. In the same way, we can continue. After g (“Confirm order’) has been com- 
pleted, we arrive at an AND-split. An AND-split consumes a token from its input 
arc and creates one token on each of its output arcs. As a result, we have two tokens 
afterwards: one enabling i (“Ship product’) and one enabling j (“Emit invoice”). 
In this state we can proceed either with i or j. These activities are concurrent. In 
order to replay the case, we first execute i and j afterwards. Once i and later k is 
completed, the AND-join is allowed to proceed. One token on each of its input arcs 
is required for that. Both these tokens are consumed and a single token is created on 
its output arc. As a result, / (“Archive order’) can be executed. 

Based on the concept of token replay, we can also assess the conformance of a 
trace to a process model. Consider the case (a, b,i, j,k, 1) in which the confirma- 
tion of the order has been omitted. The idea is to compare at each step the number 
of tokens that are required for replaying an activity with tokens that are actually 
available. At each step, we might observe two situations of conformance and two 
of non-conformance. In case of conformance, we can count the following four facts 
for tokens: 


p: the number of tokens that are correctly produced 

c: the number of tokens that are correctly consumed 

e m: the number of tokens that are missing for executing the next activity in the 
log, and 

e r: the number of tokens remaining unconsumed after executing the final activity 

in the log 


Figure 10.12 first shows the state before replaying b of the case (a, b,i, j, k,l). 
After replaying b, there is a token available to execute g, but it is not consumed. 
Instead, there is a missing token for firing the AND-split, which would activate 
i and j. The figure also shows the number of correctly produced and consumed 
tokens for each step until the completion. Using the four measures c, p, m and r, 
we can calculate the fitness measure as an indicator of conformance. It is defined 
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Fig. 10.12 Replaying the non-conforming case (a, b, i, j,k, 1) 
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Fig. 10.13 Result of replaying cases in the process model 


based on the fraction of missing tokens to correctly consumed tokens (7) and the 
fraction of remaining tokens to produced tokens G) as 


, me 1 m ie 1 r 
fines = 5 F 5 a 


For our values c = 12, p = 12, m = 1 and r = 1, we get a fitness of 5(1 _ 


>) + 5(1 _ >) = 0.8333. When we consider a set of cases, not just a single 
case, we can easily calculate the fitness in the same way. The idea is to simply 
continue counting c, p, m and r by replaying the next case in the process model. 
Once we have replayed all cases, we get the resulting overall fitness of this set of 
cases. 

The results of such a conformance analysis can be interpreted in two ways. First, 
we can use the overall fitness measure to get an idea of how accurately the pro- 
cess model matches the actually observed behavior as reflected by the set of cases. 
While the fitness as an overall measure is useful to this end, it does not help us to 
analyze the deviations in more detail. Therefore, and secondly, we can inspect at 
which arcs of the process model we have encountered missing or remaining tokens. 
Figure 10.13 shows the corresponding numbers from replaying several cases in the 
process model. It can be seen that apparently most deviations relate to activity g and 
some to activity /. This information can be utilized to interview process participants 
why g has been omitted for some cases. The goal of such an inquiry would be to find 
whether this omission is desirable. The question is whether the process participants 
have found a more efficient way to handle the confirmation, or whether an omission 
has to be considered bad practice which should be further discouraged. For the case 
of the archival (activity /), the omission is likely to be bad practice. 


10.4.2 Conformance of Data and Resources 


Beyond constraints on the control flow, there are often additional constraints on data 
and resources. Consider the situation that an expensive caterpillar is requested for 
a construction site of BuildIT. Many companies have extra rules for high expenses 
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or risky commitments. In the case of BuildIT, the rent of the caterpillar requires 
the additional signature of a manager. Similar cases can be found in banks where a 
loan of more than €1,000,000 might require the additional sign-off from a director. 
There might also be constraints that providing a loan to a black-listed applicant is 
simply not allowed at all. Such constraints can be checked by searching for cases in 
the log where a certain data field takes a forbidden value. 

The example of the additionally required signature already points to a combina- 
tion of data and resource constraints. If a certain amount is exceeded, then there is a 
dedicated resource who is required to approve. However, there are also constraints 
that purely refer to the resource perspective. Participants usually require permissions 
to execute certain activities. For instance, the person signing off the caterpillar rent 
has to be a manager, and it is not allowed that this person is a construction worker. 
Typically, permissions are bundled for specific roles. For example, this can be done 
by explicitly listing what a manager and a construction worker are allowed to do. 
Violations of permissions can be checked by searching for each activity conducted 
by a participant whether or not an appropriate role or permission existed. Specific 
control rules which require two different persons to approve a business transaction 
are called separation of duties constraints. These rules do not necessarily involve su- 
pervisors. For example, it might be OK with a particular bank if a loan of € 100,000 
is signed by two bank clerks, while a €1,000,000 loan requires the signature of a 
clerk and a director. Such separation of duties constraints can be checked by search- 
ing for cases in the log where the same participant or two participants with the same 
role have approved the same transaction. 


Exercise 10.12 Consider the intake process after the medical file redesign, which is 
shown in Fig. 8.3. Which separation of duties constraints would you define for this 
process? 


10.5 Recap 


In this chapter we discussed the topic of process intelligence. The starting point 
for process intelligence is the availability of event logs and, in general, data on 
the execution of processes. These data provides the basis for process monitoring 
and process controlling. Such event logs have to refer to a specific case, a task 
and a point in time in order to facilitate process-related analysis. In many cases, 
it is a challenge to extract data in such a way that it can readily support process 
intelligence. 

An important area of process intelligence is automatic process discovery. Cor- 
responding techniques like the w-algorithm yield process models describing how a 
process runs in reality according to the log data. The a-algorithm is a good exam- 
ple for how automatic process discovery works. However, it has some limitations 
in terms of robustness, which are addressed by more recent process mining algo- 
rithms. 
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Event logs also support the assessment of the performance of a process. We dis- 
cussed the four dimensions of the Devil’s Quadrangle. The time dimension of a 
process can be visualized as a dotted chart and further inspected using a timeline 
chart. Then, we demonstrated that the calculation of costs for a process heavily de- 
pends upon the level of detail with which execution times of tasks are captured. We 
turned to quality and related it to the number of repetitions that are encountered in a 
log. Finally, we discussed ways of quantifying the flexibility of a process based on 
the number of distinct executions, optionality and discovered decision points. 

The area of conformance checking can be related to various types of constraint. 
There are different types of constraint that can be checked for control flow including 
mandatoriness, exclusiveness and ordering of activities. A notion of fitness can be 
calculated based on replaying the logs in a normative process model. Finally, we 
discussed important types of constraint for the data and the resource perspectives. 
Often, these are intertwined. They typically relate to additional requirements for 
approval beyond a certain monetary threshold or to enforce separation of duties in 
order to control risks of a business transaction. 


10.6 Solutions to Exercises 


Solution 10.1 It might be the case that parts of the production process are admin- 
istered using different information systems. Accordingly, the event logs have to be 
integrated. In terms of correlation, this means that case identifiers from different 
systems have to be matched. If the timestamps of the events are recorded in dif- 
ferent time zones, they have to be harmonized. Shipment might not be arranged 
by Airbus. Therefore, it might be the case that different snapshots of transportation 
might not be accessible. Also, information systems might not be directly producing 
case-related event logs. The data would then have to be extracted from the databases 
of these systems. Finally, the events might be recorded at diverging levels of granu- 
larity, ranging from a detailed record of production steps to coarse-granular records 
of transportation stages. 


Solution 10.2 The workflow log considers the order of events for each case. We 
use letters a to / for referring to the tasks. The workflow log L containing three 
elements as the first and the fourth execution sequence are the same. Therefore, we 
get L =[(a,b, g,h, j,k,i,l), (a,c,d,e, f,g,j,h,i, k,l), (a,c, f, g, j,h, i,k, 1]. 


Solution 10.3 The following basic relations can be observed: 


a>b|\|h>j|i>l|d>e\|\g>j|i>k 


b>g|j>k|a>c\le>f|j>h| kl 


g>h|k>i|c>d|f>g|h>i |c>f 


The matrix shows the resulting relations. 
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Fig. 10.14 Process model constructed by the w-algorithm 


Solution 10.4 The a-algorithm stepwise yields the following sets: 


1. Ty = {a,b,c,d,e, f, g,h,i, j,k, lh. 

2. Ty = {a}. 

3. To = {i}. 

4. X, =Z,UZ2 with Z; = {a> b,a->c,b—> g,c>d,c— f,d-e,e— f, 
froegrhgr>jhoiicl,j>k,k > I} and Z2 = {a > (bic), 
c—> (d#f), (cHe) > f, DH) > g} 

5. Yp=Z2U{d>e,grh,gojhoi,jokicl,k—ol. 

6. Add start event pointing to a and end event following after /. 

7. Construct process model based on Y;, with XOR- and AND-gateways. 

8. Return process model, see Fig. 10.14. 
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Solution 10.5 Include a, b,c,d,e in an XOR-block and put this XOR-block in an 
XOR-loop. This model shows a perfect fitness to the execution sequence as it is 
able to replay any occurrence of a to e at any stage. The model is not completely 
simple as it includes four gateways for characterizing the behavior of five activities. 
Also, the model is not very precise in this sense that it does not introduce spe- 
cific constraints on the behavior: any occurrence of a to e is allowed at any stage. 
Generalization refers to the ability of the model to abstract. As the model does not 
constrain the behavior, there is hardly any general insight that we can learn from it. 


Solution 10.6 First, we have to determine the cycle time. Case | takes roughly two 
hours less than seven days, case 2 one hour less than six days, case 3 takes four days 
and 20 minutes, and case 4 takes four days and six hours. Therefore, the relative 
order must be case 3, case 4, case 2 and case 1. Each event has to be visualized 
according to the time elapsed since the first event of the case. 


Solution 10.7 The timeline diagram follows the same principle as the dotted chart. 
Additionally, it shows waiting times as soon as an activity becomes enabled in the 
process model. 


Solution 10.8 In general, it is a good idea to include all expenses in the cost calcu- 
lation as it provides transparency on what is spent where. In this case, however, it 
might not be a good idea since the cost per paper is relatively low with €0.02. It has 
to be kept in mind though that the decision whether to record certain costs should 
not be governed by the unit piece, but by the relative impact on cost calculation. 
A cost of paper of €0.02 is small as compared to overall process costs of several 
thousand Euros. However, it can be relatively high if the overall process produces 
€0.30 costs per instance and millions of instances are processed per day. Think of 
the situation of processing bank transactions using paper forms versus using online 
banking. The high amount of transactions per day might result in considerable costs 
per year. 

Solution 10.9 The formula yields r = 1 — G =15 $3 = 0.333. Apparently, this 
result is misleading for the figures because every second task required rework. How- 
ever, the rework time was in general much smaller as the first try duration. This has 
the effect that T appears to be relatively small in comparison to CT, which results 
in a low value for r. 


Solution 10.10 We have to consider four different cases. However, as the first and 
the fourth case show the same sequence of tasks, there are three distinct executions. 


Solution 10.11 There are several activities that can be observed in all cases. These 
mandatory activities are a, g,h,i, j,k,1. The other activities b,c,d,e, f are not 
mandatory. Exclusiveness relationships hold between b and c,d, e, f pairwise. 


Solution 10.12 The intake process demands meeting two intakers. The persons con- 
ducting “Meet with first intaker” and “Meet with second intaker’” should be mutually 
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exclusive. Therefore, we can identify a separation of duty constraint that the partic- 
ipant conducting “Meet with first intaker” should be another one as the participant 
conducting “Meet with second intaker”’. 


10.7 Further Exercises 


Exercise 10.13, Download the process mining tool ProM, write down the workflow 
log L in XES, and run the a-algorithm. 


Exercise 10.14 Apply the a-algorithm and document the different steps for the 
workflow log L containing four cases L = [(a, b,c, d), (a,b, d,c), (a,b, d,c,e), 
(a,c, d,e)]. 


Exercise 10.15 Apply the a-algorithm and document the different steps for the 
workflow log L containing four cases L = [(a, b,c, d,e, f), (a,b, d,c, e), (a,b, d, 
c,é, f), (a, b,c, d)]. 


Exercise 10.16 Consider there is an AND-split in a process model with two sub- 
sequent activities a and b. Which kind of pattern do these activities show on the 
timeline chart? 


Exercise 10.17 Consider the workflow log, which you created for Exercise 10.2 
from the cases shown in Fig. 10.1. Replay these logs in the process model of 
Fig. 10.13. Note down consumed, produced, missing and remaining tokens for each 
arc, and calculate the fitness measure. Assume that activities not shown in the pro- 
cess model do not change the distribution of tokens in the replay. 


10.8 Further Reading 


Process intelligence relates to various streams of current research. The workflow 
resource patterns give an extensive account of strategies that can be used for effec- 
tively assigning work items to participants at the time of execution. Process mining 
has been a very influential area of research in the recent years, offering various 
tools and techniques for process intelligence. An excellent overview of this research 
area is provided in the book by van der Aalst on process mining [94]. Among oth- 
ers, it summarizes work on leveraging shortcomings of the a-algorithm, namely the 
heuristic miner, the fuzzy miner, and the genetic miner. The idea of the heuristic 
miner is to generate so-called heuristic nets in which the arc probabilities are in- 
cluded. Using appropriate threshold values, the user can eliminate unlikely behav- 
ior. The fuzzy miner takes correlations between events and behavior into account. In 
this way, tasks can be clustered and inspected at different levels of abstraction. The 
genetic miner generates a population of potential models and stepwise manipulates 
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these models using change operations and quality metrics in order to improve the 
approximation of the log. This process is repeated until a model with a predefined 
quality level is found. 

Various guiding principles and research challenges for process mining have been 
formulated by the IEEE Task Force on Process Mining in the Process mining man- 
ifesto [37]. There are dedicated tools that help with putting process mining into 
practice (see http://www.processmining.org). Process mining tools usually cover au- 
tomatic process discovery and techniques for conformance checking. 

A good summary of current research on process performance analysis is provided 
by the BPM Handbook [102, 103] and, most notably, its chapters on process perfor- 
mance management and on business process analytics [33, 111]. A good overview 
on process controlling and its relationship to process automation is the book by zur 
Muehlen [110]. More generally, the book by Harmon provides a good perspective 
on how to define process measures within a process governance framework [32]. 
A good book on foundations on performance from an operations management point 
of view is the book by Anupindi et al. [4]. Various metrics for event logs are dis- 
cussed in the Ph.D. thesis of Giinther [25]. 

Conformance checking is also nicely covered in the book by van der Aalst on 
process mining [94]. Research with a focus on generating constraints from process 
models for conformance checking is conducted by Weidlich et al. [104, 105]. Case 
studies on process mining and conformance checking are, among others, reported 
in [13, 22, 97]. Separation of duties is traditionally discussed as a topic within the 
research area of role-based access control (RBAC). A summary of essential RBAC 
concepts and their relationship to process-centered concepts is provided in [90]. 
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